DESCRIPTION 



INFORMATION COMMUNICATION SYSTEM, INFORMATION 
COMMUNICATION METHOD, INFORMATION SIGNAL PROCESSING 
DEVICE AND INFORMATION SIGNAL PROCESSING METHOD, 
AND STORAGE MEDIUM 

Technical Field 

The present invention relates to an information 
signal processing apparatus connected to a 
communication control network and an information signal 
processing method and, more particularly, to an 
information signal processing apparatus connected to an 
IEEE 1394-compliant communication control bus and an 
information signal processing method. 

Moreover, the present invention relates to an 
information communication system having a first 
communication control network, a second communication 
network different from the first communication control 
network, and a connection device for enabling 
communication between the first communication control 
network and the second communication network, and an 
information communication method and, more particularly, 
to an information communication system connected by, 
e.g., an IEEE 1394 serial interface, and an information 
communication method. 
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Background Art 

A serial bus interface such as an IEEE 1394 
interface can simultaneously connect a plurality of 
devices such as a DV (Digital Video) , DC (Digital 
5 Camera) , host computer, scanner, and VTR, unlike a 

so-called Centronics parallel interface for one-to-one 
connection between a host computer and a terminal 
(device) . This serial bus interface can realize a data 
communication network system or home network 
10 constructed by connecting a plurality of devices based 

on an IEEE 1394 standard as one of serial bus standards. 

Various devices are connected to these networks, 
and many unspecified devices of different manufacturers 
may be connected. 
15 According to IEEE 1394-1995, a maximum of 63 

nodes can be connected to one 1394 bus (to be referred 
to as a "local bus" hereinafter) by an IEEE 1394 serial 
bus address designation method. If a 10-bit address 
space is defined for designation of a bus ID for 
20 specifying a bus, 1,023 buses can be connected to each 
other. In a cable environment, a cable between 
information signal processing apparatuses (to be 
referred to as "nodes" hereinafter) serving as devices 
is 4.5 m long at maximum. 
25 To solve technical limitations posed when more 

than a connectable maximum of 63 devices are to be 
connected via an IEEE 1394 bus or a plurality of IEEE 



1394 buses located at remote places are to be connected 
to each other, a device called a "1394 bridge" is 
generally used. By connecting a plurality of IEEE 1394 
local buses via 1394 bridges, devices connected to the 
different local buses can communicate data. 

In IEEE 1394, when the bus configuration changes 
by, e.g., an increase/decrease in the number of nodes 
upon insertion/removal of a device node, ON/ OFF 
operation of the power supply, activation by hardware 
detection owing to a network error, or a direct 
instruction under host control from a protocol, a new 
network configuration must be recognized. In this case, 
each node which has detected the change transmits a bus 
reset signal to execute a mode in which a new network 
configuration is recognized. 

This bus reset signal is transmitted to another 
nodes on the local bus. After all the nodes detect the 
bus reset signal, bus reset starts. When bus reset 
starts, data transfer is temporarily suspended. After 
the bus reset is finished, the suspended data transfer 
is restarted in a new network configuration. 

In a device connected to an IEEE 1394 bus, a 
physical layer and data link layer in a transfer 
protocol are defined by IEEE 1394. As for the upper 
layer, various upper protocols are defined and 
implemented in accordance with the intended use and 
application of a device. 
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The upper protocols of IEEE 1394 determine a 
connection establishment method in communicating data 
with a specific device using an IEEE 1394 bus, a 
resource management method, an application data 
5 transmission/reception method, a connection 

cancellation method at the end of data transfer, a 
resume method in bus reset which is a feature of IEEE 
1394 in addition to resume from an error, and protocols 
before and after bus reset. 

10 A DPP (Direct Print Protocol) as an example of 

the upper protocols defines that when bus reset occurs, 
a device which establishes a connection at the start of 
data transfer issues a reset command, and the other 
device returns an acknowledge upon reception of the 

15 command, thereby restarting data transfer. 

An AV/C protocol defines that when bus reset 
occurs before a node which has received an AV/C command 
issued by the other node sends a response, the command 
itself becomes invalid, and the command issuing node 

20 cannot expect any response. 

In this manner, when IEEE 1394 bus reset occurs, 
data transfer is temporarily suspended, and the network 
topology changes before and after bus reset. An upper 
protocol layer must cope with such a status change, so 

25 that the protocol standard defines procedures on both 
the data transmitting and receiving sides upon 
occurrence of bus reset. This definition allows 
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continuing data transfer between devices which 
implement the same upper protocol without any influence 
because, if bus reset occurs, the data transmitting and 
receiving sides execute the defined appropriate 
5 processes in data transfer. 

However, if bus reset occurs on one local bus 
connected to another IEEE 1394 bus, the IEEE 1394 
bridge does not transfer the bus reset signal to the 
other local bus (to be referred to as a "remote bus" 
10 hereinafter), i.e., does not propagate bus reset 

between the busses. Therefore, an error may occur in 
data transfer between nodes via the bridge. 

When data is transferred between devices on the 
same local bus using the above-mentioned upper 
15 protocols, bus reset is transmitted to all the nodes on 
the local bus. Accordingly, both the data transmission 
and reception nodes can detect bus reset, and can 
appropriately execute bus reset procedures by the upper 
protocols . 

20 However, if bus reset occurs on one local bus 

during data transfer from a data transmission node on 
the local bus to a data reception node connected to the 
other local bus via an IEEE 1394 bridge, the IEEE 1394 
bridge does not propagate bus reset to the other bus. 

25 Therefore, the node connected to the remote bus cannot 
detect the bus reset, only the device connected to the 
local bus executes a bus reset procedure by the upper 
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protocol layer, and the processes between the data 
transmitting and receiving sides are inconsistent. 

Disclosure of Invention 
5 It is an object of the present invention to 

provide a communication network system capable of 
performing normal data communication between 
communication control networks while maintaining the 
consistency of network configuration update request 

10 processing in an upper protocol layer in a system 

constituted by connecting a plurality of communication 
control networks (e.g., IEEE 1394 buses) via a 
connection device (e.g., IEEE 1394 bridge). 

It is another object of the present invention to 

15 provide a communication network system capable of 
performing normal data communication between buses 
while maintaining the consistency of bus reset 
processing in an upper protocol layer in a system 
constituted by connecting a plurality of communication 

20 control networks (e.g., IEEE 1394 buses) via a 
connection device (e.g., IEEE 1394 bridge). 

Other features and advantages of the present 
invention will be apparent from the following 
description taken in conjunction with the accompanying 

25 drawings, in which like reference characters designate 
the same or similar parts throughout the figures 
thereof. 
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Brief Description of Drawings 

Fig. 1 is a block diagram showing the schematic 
configuration of the first embodiment according to the 
5 present invention; 

Fig. 2 is a view showing an example of a 1394 
network configuration in the first embodiment ; 

Fig. 3 is a block diagram for explaining the 
architecture of an IEEE 1394 standard in the first 
10 embodiment ; 

Fig. 4 is a view showing services which can be 
provided by a link layer in the first embodiment ; 

Fig. 5 is a view showing services which can be 
provided by a transaction layer in the first 
15 embodiment; 

Fig. 6 is a view for explaining the address space 
of a 1394 serial bus in the first embodiment; 

Fig. 7 is a view showing an example of the 
address and function of information stored in a CSR 
20 core register in the first embodiment; 

Fig. 8 is a view showing an example of the 
address and function of information stored in a serial 
bus register in the first embodiments- 
Fig. 9 is a view showing a structure of a 
25 configuration ROM of the minimum format in the first 
embodiment; 

Fig. 10 is a view showing a structure of a 
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configuration ROM of the general format in the first 
embodiment ; 

Fig. 11 is a view showing an example of the 
address and function of information stored in the 
5 serial bus register of a unit space in the first 
embodiment ; 

Fig. 12 is a sectional view showing a 1394 serial 
bus cable in the first embodiment; 

Fig. 13 is a view showing a DS-link coding scheme 
10 in the first embodiment; 

Fig. 14 is a view for explaining a state after 
activation of bus reset in the 1394 network in the 
first embodiment; 

Fig. 15 is a flow chart showing processing from 
15 the start of bus reset to assignment of a node ID in 
the first embodiment; 

Fig. 16 is a flow chart showing details of 
parent-child relationship declaration processing in 
step S1502 shown in Fig. 15; 
20 Fig. 17 is a flow chart showing details of node 

ID setting processing in step S1505 shown in Fig. 15; 

Fig. 18 is a view showing a format of a self ID 
packet in the first embodiment ; 

Figs. 19A and 19B are views for explaining 
25 arbitration in the 1394 network in the first 
embodiment ; 

Fig. 20 is a view for explaining a case wherein 



asynchronous and isochronous transfer modes are mixed 
in one communication cycle in the first embodiment; 

Fig. 21 is a view showing the format of a 
communication packet transferred based on the 
5 isochronous transfer mode in the first embodiment; 

Fig. 22 is a view showing the format of a 
communication packet based on the asynchronous transfer 
mode in the first embodiment; 

Fig. 23 is a block diagram showing the 
10 arrangement of the 1394 interface block of a 1394 node 
in the first embodiment; 

Fig. 24 is a view showing the format of storage 
data in the configuration ROM in the first embodiment; 

Fig. 25 is a view showing the address space of 
15 the 1394 node in the first embodiment; 

Fig. 26 is a view showing the serial bus register 
area of the 1394 node in the first embodiment; 

Fig. 27 is a view showing the REMOT E_BU S_RE S ET 
register of the 1394 node in the first embodiment ; 
20 Fig. 28 is a view showing communication control 

procedures complying with a DPP protocol in the first 
embodiment ; 

Fig. 2 9 is a view showing communication control 
procedures complying with an AV/C protocol in the first 
2 5 embodiment ; 

Fig. 30 is a view showing the serial bus register 
area of a 1394 node in the second embodiment according 
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to the present invention; 

Fig. 31 is a view showing details of the 
NOTIFY BUS_RESET register of the 1394 node in the 
second embodiment; 

Fig. 32 is a block diagram showing the detailed 
arrangement of a 1394 bridge in the second embodiment; 

Fig. 33 is a view showing communication control 
procedures complying with a DPP protocol in the second 
embodiment ; 

Fig. 34 is a view showing communication control 

procedures complying with an AV/C protocol in the 

second embodiment; 

Fig. 35 is a view showing communication control 

procedures complying with a DPP protocol in the third 

embodiment according to the present inventions- 
Fig. 36 is a block diagram showing the 

configuration of the fourth embodiment according to the 

present invention; 

Fig. 37 is a view showing communication control 

procedures complying with a DPP protocol in the fourth 

embodiment ; 

Fig. 38 is a view showing communication control 
procedures complying with an AV/C protocol in the 
fourth embodiment; 

Fig. 39 is a view showing the serial bus register 
area of a 1394 node in the fifth embodiment according 
to the present invention; 



Fig. 4 0 is a view showing communication control 
procedures complying with a DPP protocol in the fifth 
embodiment; and 

Fig. 41 is a view showing communication control 
procedures complying with an AV/C protocol in the fifth 
embodiment . 

Best Mode for Carrying Out the Invention 

Preferred embodiments of present invention will 
be described in detail below with reference to the 
accompanying drawings. 
[First Embodiment] 

Fig. 1 is a block diagram showing the schematic 
configuration of the first embodiment according to the 
present invention. The first embodiment is constituted 
by two IEEE 1394-compliant local buses A 102 and B 103, 
and a 1394 bridge 101 for connecting them. Fig. 1 
shows two local buses, but a larger number of local 
buses can be connected via 1394 bridge devices. 

Each local bus has a bus ID as bus specifying 
information for specifying each local bus. The local 
bus A 102 represented by a bus ID " 3FDh" and the local 
bus B 103 represented by a bus ID "3FEh" are connected 
to a plurality of device nodes. 

In the first embodiment shown in Fig. 1, a node 
Al (104) connected to the local bus A 102 is a digital 
still camera, and a node A2 (105) is a digital video 
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cam coder. A node Bl (106) connected to the local bus 
B 103 is a printer, and a node B2 (107) is a digital 
video cam coder. 

The node Al (104) implements a direct print 
5 protocol standardized in advance as an upper protocol, 
whereas the node A2 (105) implements a standardized 
AV/C protocol. 

Similarly, the node Bl (106) connected to the 
local bus B 103 implements a direct print protocol as 
10 an upper protocol, whereas the node B2 (107) implements 
an AV/C protocol. 

<Technical Overview of IEEE 13 94 Standard> 
The technique of the IEEE 1394-1995 standard 
applied to the digital interface shown in Fig. 1 of the 
15 first embodiment will be explained. Details of the 

IEEE 1394-1995 standard (to be referred to as the "IEEE 
1394 standard" hereinafter) are described in "IEEE 
Standard for a High Performance Serial Bus" published 
by IEEE (The Instituted of Electrical and Electronics 
20 Engineers, Inc.), August 30, 1996. 
(1) Overview 

Fig. 2 shows an example of a communication system 
(to be referred to as a "1394 network") constituted by 
nodes having digital interfaces complying with the IEEE 
25 1394 standard (to be referred to as "1394 interfaces") . 
The 1394 network constitutes a bus type network capable 
of communicating serial data. 
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In Fig. 2, nodes A to H are connected via an IEEE 
1394 standard-compliant communication cable. These 
nodes A to H are electronic devices such as a PC 
(Personal Computer), digital VTR (Video Tape Recorder), 
5 DVD (Digital Video Disc) player, digital camera, hard 
disk drive, and monitor. 

The connection method of the 1394 network may 
include both a daisy chain method and node branch 
method, and enables connection with a high degree of 
10 flexibility. 

The 1394 network automatically performs bus reset 
when, e.g., an existing device is removed, a new device 
is added, or an existing device is turned on/off. By 
performing this bus reset, the 1394 network can 
15 automatically recognize a new configuration and assign 
ID information to each device. This function allows 
the 1394 network to always recognize the network 
configuration . 

The 1394 network also has a function of relaying 
20 data transferred from another device. This function 

allows all the devices to grasp the operation status of 
the bus. 

The 1394 network has a function called plug & 
play. This function allows the 1394 network to 
25 automatically recognize connected devices by only 

connecting them without turning off all the devices. 

The 1394 network copes with data transfer speeds 
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of 100/200/400 Mbps. A device having a higher data 
transfer speed can support a lower data transfer speed, 
so that devices having different data transfer speeds 
can be connected. 
5 The 1394 network further copes with two different 

data transfer schemes (i.e., asynchronous and 
isochronous transfer modes) . 

The asynchronous transfer mode is effective in 
transferring data (i.e., a control signal and file 

10 data) which should be asynchronously transferred if 

necessary. The isochronous transfer mode is effective 
in transferring data (i.e., video data and audio data) 
which should be successively transferred by a 
predetermined amount at a constant data transfer speed. 

15 The asynchronous and isochronous transfer modes 

can be mixed in each communication cycle (one cycle is 
generally 125 £iS). Each transfer mode is executed 
after transfer of a cycle start packet (to be referred 
to as a "CSP" ) representing the start of the cycle. 

20 In each communication cycle period, the 

isochronous transfer mode has higher priority than that 
of the asynchronous transfer mode. The transfer band 
of the isochronous transfer mode is ensured in each 
communication cycle. 

25 (2) Architecture 

The architecture of the IEEE 1394 standard will 
be described with reference to Fig. 3. Fig. 3 is a 



block diagram showing the architecture of the IEEE 1394 
standard in the first embodiment. 

The building elements of the IEEE 1394 interface 
will be explained. The IEEE 1394 interface is 
functionally made up of a plurality of layers 
(hierarchies) . In Fig. 3, the IEEE 1394 interface is 
connected to the IEEE 1394 interface of another node 
via an IEEE 1394 standard-compliant communication cable 
301. The IEEE 1394 interface has one or more 
communication ports 302, and each communication port 
302 is connected to a physical layer 303 included in 
hardware . 

In Fig. 3, the hardware is comprised of the 
physical layer 303 and a link layer 304. The physical 
layer 303 performs a physical and electrical interface 
with another node, detection of bus reset and its 
processing, encoding/decoding of input and output 
signals, and arbitration of bus access. The link layer 
304 performs generation and transmission/reception of a 
communication packet, and control of the cycle timer. 

In Fig. 3, the firmware includes a transaction 
layer 305 and serial bus management 30 6. The 
transaction layer 305 manages the asynchronous transfer 
mode, and provides various transactions (read, write, 
and lock) . The serial bus management 30 6 provides a 
function of controlling the self node, managing the 
connection state of the self node, managing the ID 
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information of the self node, and managing the resource 
of the serial bus network on the basis of a CSR 
architecture (to be described later) . 

The hardware 303 and 304 and the firmware 305 and 
306 substantially constitute a 1394 interface. The 
basic configuration is defined by the IEEE 1394 
standard. 

An application layer 307 included in the software 
changes depending on application software to be used, 
and controls how to communicate data on the network. 
For example, for moving picture data of a digital VTR, 
the application layer 307 is defined by a communication 
protocol such as an AV/C protocol. 

(2-1) Function of Link Layer 304 

Fig. 4 is a view showing services which can be 
provided by the link layer 304. In Fig. 4, the link 
layer 304 provides the following four services: 
© Link request (LK_DATA . request ) for requesting 
transfer of a predetermined packet of a response node 
(2) Link indication (LK_DATA. indication) for indicating 
reception of a predetermined packet to a response node 
(D Link response (LK_DATA. response) representing 
reception of an acknowledge from a response node 
® Link confirmation (LK_DATA. confirmation) for 
confirming an acknowledge from a request node 
Note that the link response (LK_DATA. response) does not 
exist in broadcast communication and the transfer of an 
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isochronous packet. 

Based on these services, the link layer 304 

realizes the two transfer schemes, i.e., asynchronous 

and isochronous transfer modes. 

(2-2) Function of Transaction Layer 305 
Fig. 5 is a view showing services which can be 

provided by the transaction layer 305. In Fig. 5, the 

transaction layer 305 provides the following four 

services : 

® Transaction reguest (TR_DATA. request ) for requesting 
a predetermined transaction of a response node 

(2) Transaction indication (TR_DATA. indication) for 
indicating reception of a predetermined transaction 
request to a response node 

(3) Transaction response (TR_DATA. response ) representing 
reception of state information (including data for 
write and lock) from a response node 

© Transaction confirmation (TR_DATA. confirmation) for 
confirming state information from a request node 

Based on these services, the transaction layer 
305 manages asynchronous transfer, and realizes the 
following three transactions: 
CD Read transaction 

(2) Write transaction 

(3) Lock transaction 

In (D read transaction, a reguest node reads 
information stored at a specific address of a response 
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node . 

In (2) write transaction, the request node writes 
predetermined information at a specific address of the 
response node. 

In (3) lock transaction, the request node 
transfers reference data and update data to the 
response node, compares information at a specific 
address of the response node with the reference data, 
and updates the information at the specific address to 
the update data in accordance with the comparison 
result . 

(2-3) Function of Serial Bus Management 306 
The serial bus management 306 can provide the 
following three functions, i.e., ©node control, (2) 
isochronous resource manager {to be referred to as an 
"IRM"), and (3) bus manager. 

® Node control provides a function of managing 
the above-described layers, and managing asynchronous 
transfer executed with another node. 

(2) The IRM provides a function of managing 
isochronous transfer executed with another node. More 
specifically, the IRM manages pieces of information 
necessary to assign a transfer bandwidth and a channel 
number, and provides these pieces of information to 
another node. 

The IRM exists only on a local bus, and is 
dynamically selected from other candidates (nodes 
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having the IRM function) every bus reset. The IRM may- 
provide some of functions (connection configuration 
management, power supply management, speed information 
management, and the like) which can be provided by the 
bus manager {to be described below) . 

(3) The bus manager has the IRM function, and 
provides a more advanced bus management function than 
the IRM. 

More specifically, the bus manager has a function 
of performing more advanced power supply management 
(manage, for each node, information representing 
whether power can be supplied via a communication cable 
and whether power must be supplied) , more advanced 
speed information management (manage the maximum 
transfer speed between nodes) , more advanced connection 
configuration management (create a topology map) , and 
bus optimization based on these pieces of management 
information, and providing the pieces of information to 
another node. 

The bus manager can provide an application with a 
service for controlling a serial bus network. This 
service includes a serial bus control request 
(SB_CONTROL. request) , serial bus event control 
confirmation (SB_CONTR0L. confirmation) , and serial bus 
event indication ( SB_CONTROL . indication) . 

The serial bus control request 
(SB_CONTROL. request) is a service of requesting bus 
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reset by an application. 

The serial bus event control confirmation 
( SB_CONTROL . confirmation) is a service of confirming 
the serial bus control request (SB_CONTROL. request) for 
5 the application. The serial bus event indication 

(SB_CONTROL. indication) is a service of indicating an 
asynchronously generated event to the application. 
(3) Description of Addressing 

Fig. 6 is a view for explaining an address space 
10 in the 1394 interface. The 1394 interface defines a 

64-bit address space in accordance with a CSR {Command 
and Status Register) architecture complying with 
ISO/IEC 13213:1994. 

In Fig. 6, a 10-bit field 601 is used for an ID 
15 number for designating a predetermined bus, and a 6-bit 
field 602 is used for an ID number for designating a 
predetermined device (node) . The upper 16 bits will be 
called a "node ID", and each node identifies another 
node using this node ID. Each node can also perform 
20 communication with an identified partner using this 
node ID. 

The remaining 48-bit field designates an address 
space (256-Mbyte structure) of each node. Of this 
field, a 20-bit field 603 designates a plurality of 
25 areas constituting an address space. 

In the field 603, an area "0 - OxFFFFD" is called 
a memory space. 



An area " OxFFFFE " is called a private space, and 
represents addresses freely usable by each node. The 
area " OxFFFFE" is called a register space, and stores 
information common to nodes connected to a bus. Each 
node can use information of the register space to 
manage communication between nodes. 

A 28-bit field 604 designates an address where 
information common or unique to each node is stored. 

For example, the first 512 bytes in the register 
space are used for a CSR architecture core (CSR core) 
register. Fig. 7 shows the address and function of 
information stored in the CSR core register. The 
offset in Fig. 7 is a relative position from 
"OxFFFFFOOOOOOO". 

The next 512 bytes in Fig. 6 are used for a 
serial bus register. Fig. 8 shows the address and 
function of information stored in the serial bus 
register. The offset in Fig. 8 is a relative position 
from "0xFFFFF0000200" . 

The next 1,024 bytes in Fig. 6 are used for a 
configuration ROM. The configuration ROM has minimum 
and general formats, and is arranged from 
"0xFFFFF0000400". Fig. 9 shows a configuration ROM of 
the minimum format. In Fig. 9, a vender ID is a 24-bit 
numerical value uniquely assigned to each vendor by 
IEEE. 

Fig. 10 shows a configuration ROM of the general 
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format. In Fig. 10, the vendor ID is stored in a root 
directory 1002. A bus inform block 1001 and root leaf 
1005 can hold node unique IDs as unique ID information 
for identifying each node. 

The node unique ID determines a unique ID capable 
of specifying one node regardless of the manufacturer 
and model. The node unique ID is made up of 64 bits. 
The upper 24 bits represent a vendor ID, and the lower 
48 bits represent information (e.g., the manufacturing 
number of a node) freely settable by the manufacturer 
of each node. The node unique ID is used when, for 
example, a specific node is kept recognized before and 
after bus reset. 

In Fig. 10 showing the configuration ROM of the 
general format, the root directory 1002 can hold 
information about the basic function of a node. 
Detailed functional information is stored in 
subdirectories (unit directories 1004) offset from the 
root directory 1002. The unit directories 1004 store, 
e.g., information about software units supported by a 
node. More specifically, the unit directories 1004 
hold information about a data transfer protocol for 
data communication between nodes, and a command set for 
defining predetermined communication procedures. 

In Fig. 10, a node dependent info directory 1003 
can hold information unique to a device. The node 
dependent info directory 1003 is offset from the root 
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directory 1002. 

In Fig. 10, vendor dependent information 1006 can 
hold information unique to a vendor which manufactures 
or sells nodes. 

The remaining area is called a unit space, and 
designates an address where information unique to each 
node, e.g., identification information (manufacturer 
name, model name, or the like) or use conditions of 
each device are stored. Fig. 11 shows the address and 
function of information stored in the serial bus 
register of the unit space. The offset in Fig. 11 is a 
relative position from "OxFFFFF0000800" . 

In general, to simplify the design of different 
types of bus systems, each node should use only the 
first 2,048 bytes of the register space. In other 
words, the bus system is desirably constituted by 4,096 
bytes as a total of the CSR core register, the serial 
bus register, the configuration ROM, and the first 
2,04 8 bytes of the unit space. 

(4) Structure of Communication Cable 
Fig. 12 is a sectional view showing an IEEE 
1394-compliant communication cable. 

The communication cable is made up of two 
twisted-pair signal lines and a power supply line. 
This power supply line can supply power even to a 
device whose main power supply is turned off, or a 
device which decreases in power due to a failure. The 



power supply voltage flowing through the power supply 
line is defined as 8 to 40 V, and the current is 
defined as a maximum of DC 1.5 A. 

The two twisted-pair signal lines transmit 
information signals encoded by a DS-link (Data/Strobe 
link) coding scheme. Fig. 13 is a view for explaining 
the DS-link coding scheme in the first embodiment. 

The DS-link coding scheme shown in Fig. 13 is 
suitable for high-speed serial data communication, and 
requires two twisted-pair lines. One twisted-pair line 
transmits a data signal, whereas the other twisted-pair 
line transmits a strobe signal. The receiving side can 
regenerate a clock by exclusive-ORing the data and 
strobe signals received from the two signal lines. 

The 1394 interface using the DS-link coding 
scheme attains the following advantages: 
0 The transfer efficiency is higher than other coding 
schemes . 

(2) The PLL circuit can be omitted to downsize the 
controller LSI. 

(3) Information representing an idle state need not be 
transmitted, so that the transceiver circuit can easily 
change to a sleep state to reduce the power consumption. 

(5) Bus Reset Function 

The 1394 interface of each node can automatically 
detect a change in network connection configuration. 
In this case, the 1394 network executes processing 



called bus reset by the following procedures. A change 
in connection configuration can be detected by a change 
in bias voltage applied to the communication port of 
each node. 

A node which has detected a change in network 
connection configuration (e.g., an increase/decrease in 
the number of nodes upon insertion/removal of a node or 
ON/OFF operation of a node), or a node which must 
recognize a new connection configuration transmits a 
bus reset signal onto the bus via the 1394 interface. 

The 1394 interface of a node which has received 
the bus reset signal transmits occurrence of bus reset 
to its link layer 304, and transfers the bus reset 
signal to another node. A node which has received the 
bus reset signal clears the recognized network 
connection configuration and the node ID assigned to 
each device. After all the nodes detect the bus reset 
signal, each node automatically performs initialization 
processing (recognition of a new connection 
configuration and assignment of a new node ID) 
accompanying bus reset. 

Note that bus reset can be activated not only by 
a change in connection configuration described above, 
but also by directly issuing an instruction from the 
application layer 307 to the physical layer 303 under 
host control. 

After bus reset occurs, data transfer is 



temporarily suspended, and then restarted in a new 
network after completion of initialization processing 
accompanying bus reset. 

(6) Description of Sequence After Occurrence of 
Bus Reset 

After bus reset occurs, the 1394 interface of 
each node automatically executes recognition of a new 
connection configuration and assignment of a new node 
ID. A basic sequence from the start of bus reset to 
assignment processing of a node ID will be explained 
with reference to Figs. 14 to 16. 

Fig. 14 is a view for explaining a state after 
occurrence of bus reset in the 1394 network of Fig. 2. 

In Fig. 14, node A comprises one communication 
port; node B, two communication ports; node C, two 
communication ports; node D, three communication ports; 
node E, one communication port; and node F, one 
communication port. The communication port of each 
node has a port number for identifying each port. 

Processing from the start of bus reset to 
assignment of a node ID in Fig. 14 will be explained 
with reference to the flow chart of Fig. 15. Fig. 15 
is a flow chart showing processing from the start of 
bus reset to assignment of a node ID in the first 
embodiment . 

Nodes A to F shown in Fig. 14 that constitute a 
1394 network always monitor whether bus reset occurs, 



27 



as shown in step S1501. If a node which has detected a 
change in connection configuration outputs a bus reset 
signal, each node detects bus reset to execute 
processing from step S1502. 
5 If bus reset is detected, the flow advances from 

step S1501 to step S1502, and respective nodes declare 
parent-child relationships between their communication 
ports after occurrence of bus reset. In step S1503, 
whether parent-child relationships between all the 
10 nodes are determined is checked. If NO in step S1503, 
the flow returns to step S1502, and each node repeats 
processing in step S1502 until parent-child 
relationships between all the nodes are determined. 

After parent-child relationships between all the 
15 nodes are determined, the flow shifts from step S1503 
to step S1504. In step S1504, the 1394 network 
determines a node, i.e., root which performs network 
arbitration. After the root is determined, the flow 
shifts to step S1505, and the 1394 interface of each 
20 node executes an operation of automatically setting the 
self node ID. In step S1506, whether node IDs have 
been set for all the nodes to complete ID setting 
processing is checked. If NO in step S1506, the flow 
returns to step S1505, and each node sets an ID for the 
25 next node based on predetermined procedures. 

After node IDs are set for all the nodes, the 
flow advances from step S1506 to step S1507, and each 
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node executes isochronous transfer or asynchronous 
transfer. After data transfer ends, the 1394 interface 
of each node returns to step S1501 to monitor bus reset. 

By the above procedures, the 1394 interface of 
each node can automatically execute recognition of a 
new connection configuration and assignment of a new 
node ID every time bus reset occurs. 

(7) Determination of Parent-Child Relationship 
Details of parent-child relationship declaration 
processing (i.e., processing of recognizing 
parent-child relationships between nodes) in step S1502 
shown in Fig. 15 will be described with reference to 
the flow chart of Fig. 16. Fig. 16 is a flow chart 
showing details of parent-child relationship 
declaration processing in step S1502 shown in Fig. 15 
in the first embodiment. 

In parent-child relationship declaration 
processing of the first embodiment, nodes A to F on the 
1394 network confirm the connection states (connection 
or disconnection) of the self communication ports upon 
occurrence of bus reset in step S1601 shown in Fig. 16. 
After confirming the connection state of the 
communication port, each node counts in step SI 602 the 
number of communication ports (to be referred to as 
connected ports) connected to other nodes, and checks 
whether the number of connected ports is one. 

If the number of connected ports is one in step 
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S1602, the flow shifts to step S1603, and the node 
recognizes itself as a "leaf". The "leaf" means a node 
connected to only one node. In step S1604, the node 
serving as a leaf declares a "child" to a node 
5 connected to the connected port. At this time, the 
leaf recognizes that the connected port is a "parent 
port (communication port connected to a parent node)". 
After that, the flow advances to step S1611. 

Parent-child relationships are sequentially 

10 declared between a branch and a leaf serving as a 

network terminal end, and then between branches. The 
parent-child relationships between nodes are determined 
in the order of a communication port which can make a 
declaration early. A communication port which declares 

15 a child is recognized as a "parent port" between nodes, 
and a communication port which has received the 
declaration is recognized as a "child port 
(communication port connected to a child node)". For 
example, in Fig. 14, nodes A, E, and F recognize 

20 themselves as leaves, and declare child-parent 

relationships. Then, nodes A and B are determined to 
be a child and parent; nodes E and D, a child and 
parent; and nodes F and D, a child and parent. 

If the number of connected ports is not one but 

25 two or more as a result of processing in step S1602, 

the flow shifts to step S1605, and the node recognizes 
itself as a "branch". The "branch" means a node 
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connected to two or more nodes. In step S1606, the 
node serving as a branch receives declaration of a 
parent-child relationship from a node at each connected 
port. The connected port which has received the 
declaration is recognized as a "child port". 

After one connected port is recognized as a 
"child port", the flow advances to step S1607, and the 
branch detects whether there are two or more connected 
ports (i.e., undefined ports) for which parent-child 
relationships have not been determined yet. If YES in 
step S1607, the flow returns to processing in step 
S1606, and the branch receives declaration of a 
parent-child relationship from a node at each connected 
port again. 

If NO in step S1607, the flow shifts to step 
S1608, and the branch checks whether only one undefined 
port exists. If YES in step S1608, the branch 
recognizes the undefined port as a "parent port", and 
declares a "child" to a node connected to the port in 
step S1609. Then, the flow advances to step S1611. 

The branch cannot declare a child to another node 
until the number of remaining undefined ports decreases 
to one. For example, in the configuration of Fig. 14, 
nodes B, C, and D recognize themselves as branches, and 
receive declarations from leaves or other branches. 
Node D declares a parent-child relationship to node C 
after parent-child relationships between D and E and 



between D and F are determined. Node C which has 
received the declaration from node D declares a 
parent-child relationship to node B. 

If NO in step S1608 (i.e., all the connected 
ports of the branch are parent ports), the flow shifts 
to step S1610, and the branch recognizes itself as a 
root. For example, in Fig. 14, node B in which all the 
connected ports are parent ports is recognized by other 
nodes to be a root for arbitrating communication on the 
1394 network. 

In this case, node B is determined to be a root. 
If the timing at which node B declares a parent-child 
relationship is earlier than the timing at which node C 
declares a parent-child relationship, another node may 
become a root. Hence, even the same network 
configuration does not always use the same node as a 
root . 

After the parent-child relationships of all the 
connected ports are declared, each node can recognize 
the connection configuration of the 1394 network as a 
hierarchical structure (tree structure) . The 
declarations at all the connected ports end in step 
S1611, and the flow returns to the main routine. Note 
that the parent node is an upper node in the 
hierarchical structure, and the child node is a lower 
node in the hierarchical structure. 

(8) Assignment of Node ID 
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Node ID setting processing (i.e., processing of 
automatically assigning the node ID of each node) in 
step S1505 shown in Fig. 15 will be described in detail 
with reference to Fig. 17. Fig. 17 is a flow chart 
showing details of node ID setting processing in step 
S1505 of Fig. 15. The node ID is made up of a bus 
number and node number. In the first embodiment, 
respective nodes are connected to the same bus, and 
have the same bus number. 

In node ID setting processing of the first 
embodiment, the root gives node ID setting permission 
to a communication port having the smallest number 
among child ports connected to nodes whose node IDs 
have not been set yet. In Fig. 17, the root sets the 
node IDs of all the nodes connected to a child port 
having the smallest number, determines that the child 
port has been set, and performs the same control for a 
child port having the second smallest number. After 
the IDs of all the nodes connected to child ports are 
set, the root sets the self node ID. Node numbers 
contained in node IDs are basically sequentially 
assigned as 0, 1, 2,... to leaves and branches. Thus, 
the root has the largest node number. 

A node which has received the setting permission 
in step S1701 checks in step S1702 whether a child port 
including a node whose node ID has not been set yet 
exists in the self child ports. If NO in step S1702, 



the flow shifts to step S1705. 

If YES in step S1702, the flow advances to step 
S1703, and the node which has received setting 
permission gives setting permission to a node directly 
connected to the child port (child port having the 
smallest number) . In step S1704, the node which has 
received setting permission checks whether a child port 
including a node whose node ID has not been set yet 
exists in the self child ports. If YES in step S1704, 
the flow returns to step S1703, and the node gives 
setting permission to a child port having the smallest 
number . 

If NO in step S1704, the flow shifts to' step 

S1705. 

In this way, if a child port including an unset 
node is not detected in step S1702 or S1704, the flow 
shifts to step S1705, and the node which has received 
setting permission sets the self node ID. In step 
S1706, the node which has set the self node ID 
broadcasts a self ID packet containing information 
about its node number and the connection state of the 
communication port. "Broadcast" means to transfer a 
communication packet of a given node to many 
unspecified nodes constituting a 1394 network. 

Each node can receive this self ID packet to 
recognize a node number assigned to each node, and can 
recognize the assigned node number. For example, in 



Fig. 14, node B serving as a root gives node ID setting 
permission to node A connected to a communication port 
having the smallest port number Node A assigns 

"No. 0" as its node number, and sets a node ID made up 
of a bus number and the node number. Then, node A 
broadcasts a self ID packet containing the node number. 

Fig. 18 shows a format of a self ID packet output 
in step S1706. In Fig. 18, reference numeral 1801 
denotes a field for storing the node number of a node 
which has sent a self ID packet; 1802, a field for 
storing information about a compatible transfer speed; 
1803, a field representing the presence/absence of a 
bus management function (the presence/absence of a bus 
manager ability); and 1804, a field for storing 
information about power consumption and supply 
characteristics . 

In Fig. 18, reference numeral 1805 denotes a 
field for storing information about the connection 
state of a communication port having a port number "#0" 
(connection, disconnection, parent-child relationship 
of a communication port, and the like); 1806, a field 
for storing information about the connection state of a 
communication port having a port number "#1" 
(connection, disconnection, parent-child relationship 
of a communication port, and the like); and 1807, a 
field for storing information about the connection 
state of a communication port having a port number "#2" 
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{connection, disconnection, parent-child relationship 
of a communication port, and the like) . 

When a node which sends a self ID packet has a 
bus manager ability, a contender bit in the field 1803 
5 is set to "1"; otherwise, to "0". 

The bus manager is a node having a function of 
performing, based on various pieces of information 
contained in the above-mentioned self ID packet, bus 
power supply management (manage, for each node, 
10 information representing whether power can be supplied 
via a communication cable and whether power must be 
supplied) , speed information management {manage the 
maximum transfer speed between nodes from information 
about a compatible transfer speed of each node) , 
15 topology map information management (manage the network 
connection configuration from parent-child relationship 
information of a communication port) , and bus 
optimization based on topology map information, and a 
function of providing these pieces of information to 
20 other nodes. These functions allow the node serving as 
a bus manager to manage the bus over the 1394 network. 

In processing of Fig. 17, a node which has set a 
node ID after processing in step S1706 checks in step 
S1707 whether a parent node exists. If YES in step 
25 S1707, the flow returns to step S1702, and the parent 
node executes processing from step S1702, and gives 
permission to a node whose node ID has not been set yet. 
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If NO in step S1707, the node is determined to be 
a root. The flow shifts to step S1708, and the node 
serving as a root checks whether node IDs are set for 
nodes connected to all the child ports. If ID setting 
processing for all the nodes is not completed in step 
S1708 (NO), the flow returns to step S1701, and the 
root gives ID setting permission to a child port having 
the smallest number among child ports including the 
node. Then, processing after step S1702 is executed. 

If YES in step S1708, the flow shifts to step 
S1709, and the root sets the self node ID. After 
setting the node ID, the root broadcasts a self ID 
packet in step S1710. Then, the flow returns to the 
main routine. 

By this processing, the 1394 network can 
automatically assign a node ID to each node. 

If a plurality of nodes have a bus manager 
ability after node ID setting processing, a node having 
the largest node number serves as a bus manager. That 
is, when a root having the largest node number in the 
network has a bus manager function, the root serves as 
a bus manager. 

If, however, the root does not have this function, 
a node having the largest node number next to the root 
serves as a bus manager. Which node becomes a bus 
manager can be grasped by checking the contender bit 
1803 in a self ID packet broadcasted by each node. 
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(9) Arbitration Function 

Figs. 19A and 19B are views for explaining 
arbitration in the 1394 network in the first embodiment 
shown in Fig. 1. 

The 1394 network always performs bus access 
arbitration prior to data transfer. The 1394 network 
is a logical bus type network, and can transfer the 
same communication packet to all the nodes in the 
network by relaying a communication packet transferred 
from each node to another node. To prevent collision 
of communication packets, arbitration must be executed, 
which allows only one node to transfer a packet at 
given time. 

Fig. 19A is a view for explaining a case wherein 
nodes B and F issue bus access requests. 

When arbitration starts, nodes B and F issue bus 
access requests to their parents. A parent (i.e., node 

C) which has received the request from node B relays 
the bus access request to its parent node (i.e., node 

D) . This request is finally sent to a root (node D) 
which finally executes arbitration. 

The root which has received the bus access 
requests determines which node can use the bus. This 
arbitration operation can be done by only a node 
serving as a root, and a node which wins arbitration is 
permitted to use the bus. 

Fig. 19B is a view showing a case wherein a 
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request from node F is permitted, and a request from 
node B is denied. 

The root transmits a DP (Data Prefix) packet to a 
node which loses in arbitration, and notifies the node 
of denial. The denied node holds a bus access request 
until the next arbitration. 

By controlling arbitration, the 1394 network can 
manage bus access. 

(10) Communication Cycle 

In the first embodiment, the asynchronous and 
isochronous transfer modes can be mixed in time 
division in each communication cycle period. In 
general, the communication cycle period is 125 u S long. 

Fig. 20 is a view for explaining a case wherein 
the asynchronous and isochronous transfer modes are 
mixed in one communication cycle. 

In the first embodiment, the isochronous transfer 
mode is executed preferentially to the asynchronous 
transfer mode. This is because an idle period 
(subaction gap) necessary for activating asynchronous 
transfer after a cycle start packet is set longer than 
an idle period (isochronous gap) necessary for 
activating isochronous transfer. Thus, isochronous 
transfer is executed preferentially to asynchronous 
transfer. 

In Fig. 20, a cycle start packet (to be referred 
to as a "CSP" hereinafter) is transferred from a 
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predetermined node at the start of each communication 
cycle. Each node can count the same time as another 
node by adjusting the time using the CSP. 
(11) Isochronous Transfer Mode 
5 The isochronous transfer mode is an isochronous 

type transfer scheme. Isochronous mode transfer can be 
executed in a predetermined period after the start of a 
communication cycle. The isochronous transfer mode is 
always executed every cycle in order to maintain 

10 real-time transfer. 

The isochronous transfer mode is a transfer mode 
suitable for transfer of data such as moving picture 
data or audio data which requires real-time transfer. 
The isochronous transfer mode is broadcasting 

15 communication, unlike one-to-one communication in the 
asynchronous transfer mode. That is, a packet sent 
from a given node is transferred to all the nodes on 
the network. Note that isochronous transfer does not 
use any ack (acknowledge) . 

20 In Fig. 20, channel e (ch e) , channel s (ch s), 

and channel k (ch k) represent periods during which 
nodes perform isochronous transfer. The 1394 interface 
uses different channel numbers in order to discriminate 
a plurality of different isochronous transfer 

25 operations. This enables isochronous transfer between 
a plurality of nodes. In this case, the channel number 
does not specify a transmission destination, but only 
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gives a logical number to data. 

The isochronous gap shown in Fig. 20 represents a 
bus idle state. Upon the lapse of a predetermined time 
in this idle state, a node which desires isochronous 
transfer determines that it can use the bus, and 
executes arbitration. 

Fig. 21 shows the format of a communication 
packet transferred based on the isochronous transfer 
mode in the first embodiment. The communication packet 
transferred based on the isochronous transfer mode will 
be called an isochronous packet. 

In Fig. 21, the isochronous packet is made up of 
a header 2101, header CRC 2102, data 2103, and data CRC 
2104 . 

The header 2101 includes a field 2105 for storing 
the data length of the data 2103, a field 2106 for 
storing format information of the isochronous packet, a 
field 2107 for storing the channel number of the 
isochronous packet, a field 2108 for storing a packet 
format and a transaction code (tcode) for identifying 
processing which must be executed, and a field 2109 for 
storing an isochronous code. 

(12) Asynchronous Transfer Mode 
The asynchronous transfer mode of the first 
embodiment is an asynchronous type transfer scheme. 
Asynchronous transfer is one-to-one communication from 
a self node to a partner node, and can be executed 
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until the next communication cycle starts (i.e., the 
CSP of the next communication cycle is transferred) 
after the end of an isochronous transfer period. 

In Fig. 20, the first subaction gap represents a 
5 bus idle state. After the idle time reaches a 

predetermined value, a node which desires asynchronous 
transfer determines that it can use the bus, and 
executes arbitration. 

The node which gains bus access by arbitration 
10 transfers a packet shown in Fig. 22 to a predetermined 
node. The node which has received this packet returns 
ack (acknowledge) or response packet subsequently to 
ack gap. 

Fig. 22 is a view showing the format of a 
15 communication packet based on the asynchronous transfer 
mode in the first embodiment. The communication packet 
transferred based on the asynchronous transfer mode 
will be called an asynchronous packet. 

In Fig. 22, the asynchronous packet is made up of 
20 a header 2201, header CRC 2202, data 2203, and data CRC 
2204. 

In the header 2201, a field 2205 stores the node 
ID of a destination node; a field 2206, the node ID of 
a source node; a field 2207, a label representing a 
25 series of transactions; a field 2208, a code 

representing a retransmission status; a field 2209, a 
packet format and a transaction code (tcode) for 
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identifying processing which must be executed; a field 
2210, priority; a field 2211, the memory address of a 
destination; a field 2212, the length of data; and a 
field 2213, an extended transaction code. 
5 A packet transferred from a transferring node in 

asynchronous transfer is transmitted to all the nodes 
in the network, but the nodes ignore packets except for 
ones designated to the self addresses. Thus, only a 
destination node can read the packet. 

10 When asynchronous transfer reaches time at which 

the next CSP should be transferred, the next CSP is 
transmitted after the end of transfer without forcibly 
stopping transfer. If one communication cycle 
continues for 125 jj, S or more, the next communication 

15 cycle is shortened. This enables the 1394 network to 
hold an almost constant communication cycle. 
(13) Creation of Device Map 

As a means for obtaining the topology of the 1394 
network by an application in order to create a device 
20 map, the IEEE 1394 standard provides the following 
means : 

1) The topology map register of the bus manager 
is read. 

2) The topology map is estimated from a self ID 
25 packet in bus reset. 

By the means 1) and 2), the topology of a cable 
connection order based on the parent-child 
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relationships between nodes can be attained, but the 
topology of a physical positional relationship cannot 
be attained (a port which is not actually mounted is 
listed) . 

5 As another means, information for creating a 

device map is held in the database of a device other 
than a configuration ROM. In this case, the means for 
obtaining various pieces of information depends on 
protocols for database access. On the other hand, the 
10 configuration ROM itself and the function of reading it 
are necessarily attached to an IEEE 1394-compliant 
device . 

Thus, the first embodiment employs a function of 
storing information about the device position, function, 

15 and the like in the configuration ROM of each node and 
reading information by an application. Accordingly, 
the application of each node can have a so-called 
device map display function regardless of specific 
protocols for database access, data transfer, and the 

20 like. 

The configuration ROM can store a physical 
position, function, and the like as node dependent 
information. Such information can be used to realize 
the device map display function. 
25 In this case, in order for an application to 

obtain the 1394 network topology based on the physical 
positional relationship, the configuration ROM of each 
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node is read-accessed in accordance with bus reset or a 
user's request, thereby obtaining the 1394 network 
topology. Further, various pieces of node information 
such as functions in addition to the physical position 
5 of a node can be described in the configuration ROM. 
By read-accessing the configuration ROM, function 
information of each node can be attained at the same 
time as the physical position of the node. When an 
application is to acquire configuration ROM information 
10 of each node, the application uses an API for acquiring 
arbitrary configuration ROM information of a designated 
node . 

With the use of this means, the application of a 
device on the IEEE 1394 network can create various 
15 device maps such as a physical topology map and the 
function map of each node in accordance with 
application purposes. The user can select a device 
having a necessary function. 

<Overview of 1394 Bridge> 
20 The configuration and connection device in the 

first embodiment will be described. 

The technique of an IEEE 1394 bridge applied to 
the digital interface of the first embodiment will 
briefly be described. The standard of the IEEE 1394 
25 bridge (to be referred to as a "1394 bridge" 

hereinafter) is being defined by the IEEE pl394.1. 

According to the 1394 standard, a maximum of 63 
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nodes can be connected to one 1394 bus, and the hop 
count is up to 16. To connect more than 63 1394 nodes 
to a 1394 network, or connect devices at remote places 
by connecting more than 16 hops, a 1394 bridge is 
5 generally used. 

The IEEE 1394 standard uses 64-bit fixed 
addressing according to the IEEE 1212 standard, and 
defines 10 bits as a bus ID. Thus, a maximum of 1,023 
buses except for ID 1023 for designating a local bus 
10 can be connected via 1394 bridges to constitute a 1394 
network. 

The main function of the 1394 bridge is control 
of 1394 node transaction between buses via the bridge. 
In 1394 transaction, a node which issues a transaction, 

15 i.e., issuing node is designated using a node ID as 

described in <Technical Overview of IEEE 1394 Standard>. 
The 1394 bridge has a table of information such as 
topology information of two connected buses and node ID 
information, and discloses partner's bus/node 

20 information to two connected buses to enable 
transactions between the buses. 

On the 1394 bus, bus reset occurs when the 
connection configuration changes by additionally 
connecting a device node or when a certain node 

25 intentionally instructs bus reset. To automatically 
reassign a node ID upon occurrence of bus reset, the 
bus reset sequence and node ID determination sequence 
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are done to create a new topology. Details of these 
sequences are described in "(6) Description of Sequence 
After Occurrence of Bus Reset" and "(8) Assignment of 
Node ID" of <Technical Overview of IEEE 1394 Standard>, 
5 and a description thereof will be omitted. 

Because of these characteristics, topology/node 
ID information of a connected bus dynamically changes, 
and the bridge updates this information. 

During the 1394 bus reset sequence, data transfer 
10 on the bus is suspended, and a complicated node ID 

reassignment sequence is executed. It is, therefore, 
inefficient to propagate a bus reset signal to a bus 
which need not execute any bus reset sequence. For 
this reason, the 1394 bridge does not propagate the bus 
15 reset signal of one connected bus to the other bus. 

As another bridge function, the 1394 bridge has a 
packet routing function based on arbitration between 
1394 bridges and exchange of information between 
bridges in a network constituted by a plurality of 
20 buses in which a plurality of bus bridges are connected. 
The configuration and functions of the 
communication system constructed using the 1394 
interface have been described. 

[Description of Configuration and Connection 

25 Device 

in First Embodiment] 
The configuration and connection device in the 
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first embodiment will be described. The configuration 
of a 1394 serial bus interface common to respective 
nodes connected to each local bus will be explained 
with reference to Fig. 23. Fig. 23 is a block diagram 
5 showing the arrangement of the 1394 interface block of 
a 1394 node in the first embodiment. 

In Fig. 23, reference numeral 2701 denotes a link 
layer control IC (LINK IC) which interfaces a device 
main body, controls data transfer of a PHY IC, and 

10 realizes the function of the link layer in <Technical 
Overview of IEEE 1394 Standard>. The main function of 
this IC includes a transmission/reception FIFO function 
of temporarily storing transmission/reception data via 
the PHY IC, a function of packeting transmission data, 

15 a function of determining whether the PHY IC is 

suitable for an assigned channel when reception data 
has the self node address or is isochronous transfer 
data, a receiver function of performing error check for 
the data, and a function of interfacing the device main 

20 body. 

Reference numeral 2702 denotes a physical layer 
control IC (PHY IC) for directly driving the 1394 
serial bus. The physical layer control IC 2702 
realizes the function of the physical layer in 
25 <Technical Overview of IEEE 1394 Standard>. The main 
function of this IC includes bus initialization, 
arbitration, encoding/decoding of a transmission data 
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code,, monitoring of a cable ON state, supply of a load 
termination type power source (for recognizing active 
connection), and an interface with a link layer IC. 

Reference numeral 2703 denotes a configuration 
5 ROM which stores identification and communication 

conditions unique to each device. The data format of 
this ROM complies with a format defined by the IEEE 
1212 and IEEE 1394 standards, as described in 
<Technical Overview of IEEE 1394 Standard>. 

10 Reference numeral 2704 denotes a CPU for 

controlling 1394 interfaces such as the link layer IC 
and PHY IC; 2705, a ROM storing control programs for 
these interfaces; and 2706, a RAM used for a data 
buffer for storing transmission/reception data, a 

15 control work area, and the data areas of various 
registers mapped at 1394 addresses. 

Each node comprises a configuration ROM of a 
general format as shown in Fig. 24. Software unit 
information of each device is stored in a unit 

20 directory, whereas node dependent information is stored 
in a node dependent info directory. 

The basic function instance of each device such 
as a printer function or scanner function, and detailed 
information accessory to the basic function can be held 

25 by an instance directory offset from the root directory. 
The format of the instance directory will be 
described. The instance directory stores information 
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of a device such as a printer or scanner which does not 
depend on protocols. For a single-function device, 
basic function information is one. For a device which 
supports a plurality of functions, a plurality of 
5 functions are listed. For each of the listed functions, 
the instance directory stores pointer information to a 
unit directory for storing corresponding protocol 
software information, and a pointer to a feature 
directory for holding detailed information unique to 

10 each function. 

As described in <Technical Overview of IEEE 1394 
Standard>, the last 28 bits out of the address setting 
of the 1394 serial bus are ensured as the unique data 
area of each device which can be accessed by another 

15 device connected to the serial bus. Fig. 25 is a view 
showing the address space of the 28-bit area serving as 
the unique data area of each device. 

CSR core registers shown in Fig. 11 are arranged 
in an area from address 0000 to address 0200 in Fig. 25. 

20 These registers exist as basic functions for node 
management defined by the CSR architecture. 

An area from address 0200 to address 0400 is 
defined by the CSR architecture as an area for storing 
serial bus dependent registers. Fig. 26 shows an 

25 example of the area for storing serial bus dependent 
registers according to the first embodiment. As 
described in <Technical Overview of IEEE 1394 Standard>, 
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registers at address 0200 to address 0230 are defined 
and used for synchronization of data transfer, supply 
of power, management of the bus resource, and the like. 
This is the same as the arrangement shown in Fig. 12. 
5 A register REMOTE_BUS_RESET arranged at address 

0240 in Fig. 26 is a feature of the first embodiment. 
The format of this register is shown in Fig. 27. 

A node in which data prepared by substituting an 
effective bus ID in a BUS_ID field in accordance with 

10 the format of Fig. 27 is written by a 1394 write 

transaction to this register can know occurrence of bus 
reset in a remote bus represented by the BUS_ID field 
other than a local bus connected to this node. The 
above-mentioned configuration ROM is arranged in an 

15 area from address 0400 to address 0800. 

An area from address 0800 to address 1000 shown 
in Fig. 25 stores the current 1394 bus topology 
information and information about the transfer speed 
between nodes. An area after address 1000 is called a 

20 unit space where registers concerning operations unique 
to each device are arranged. This area stores 
registers and a data transfer memory mapped buffer area 
defined by upper protocols supported by each device, or 
device dependent registers. 

25 The operation of the first embodiment in a 1394 

network where devices Al and A2 each having a 1394 
interface constituted in the above manner are connected 
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to the bus A, devices Bl and B2 are connected to the 
bus B, and the buses A and B are connected by a 1394 
bridge device will be explained with reference to 
Figs. 28 and 29. Fig. 28 is a view showing 
5 communication control procedures complying with a DPP 
protocol in the first embodiment, and Fig. 29 is a view 
showing communication control procedures complying with 
an AV/C protocol in the first embodiment. 

Before the buses A and B attain their current 

10 connection configurations, bus reset independently 
occurs on each bus every time a device node is 
additionally connected. A bus reset sequence and bus 
ID determination sequence are executed to automatically 
assign a node ID upon occurrence of bus reset, and a 

15 new topology is created. 

Then, 1394 data transfer starts on each bus. 
Details of these sequences are described in "(6) 
Description of Sequence After Occurrence of Bus Reset" 
and "(8) Assignment of Node ID" of <Technical Overview 

20 of IEEE 1394 Standard>, and a description thereof will 
be omitted. Although the operation changes depending 
on the connection order of connection nodes and the 
connection order of buses to the 1394 bridge, the bus 
reset-1394 initialization sequence is repeated every 

25 time a node is connected. Finally, a topology in which 
devices Al and A2 are connected to the bus A via the 
1394 bridge 101, and devices Bl and B2 are connected to 
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the bus B is formed. 

While the topology of the 1394 network is 
determined in this state, and 1394 data transfer is 
normally performed, the node Al as a digital still 
5 camera having a direct print protocol (to be referred 
to as a "DPP") as an upper protocol searches for a 
printer device which supports the DPP on the 1394 
network, like the self node, in order to transfer image 
data to a printer connected to the 1394 network and 

10 print the image data in accordance with user operation 
or the trigger of an application. 

This is realized by read-accessing the 
configuration ROM of a partner node for a node 
connected to the network. This is shown in Fig. 19. 

15 More specifically, the node uses an IEEE 1394 read 
transaction for the partner node to receive the ROM 
contents of the partner node as a read response. 

As described above, 1394-related information is 
described in the configuration ROM of each node. 

20 Further, the basic function of each node such as a 
printer or camera is described in the instance 
directory, and an upper protocol such as an AV/C 
protocol or DPP and software information are described 
in the unit directory. 

25 While the node Al read-accesses the ROM of each 

node on the local bus A, and then read-accesses the ROM 
of each node on the bus B via the 1394 bridge, the node 



53 



Al detects that the node Bl is a printer as a DPP 
device . 

Although details of a 1394 transaction via the 
1394 bridge will be omitted, its standard is being 
5 defined by IEEE pl394.1. 

After the camera as the node Al finds the node Bl 
which is a printer and has the same protocol as the DPP 
protocol supported by the node Al, the node Al 
establishes connection with the node Bl in accordance 
10 with procedures and a format defined by the DPP 
protocol shown in Fig. 28. 

More specifically, the node Al transmits a 
connection request command to the node Bl using a write 
transaction, as shown in CD of Fig. 28. In response to 
15 this, the node Bl transmits a connection request 

response using a write transaction, as shown in (2) of 
Fig. 28. Then, transfer of application data starts. 

Similarly, the node B2 as a digital video cam 
coder having an AV/C protocol as an upper protocol 
20 starts transmission/reception of an AV/C command with 
the node A2 via the 1394 bridge using an AV/C protocol 
shown in Fig. 29. The node B2 issues an AV/C command, 
and enters a response wait state, as shown in (D of 
Fig. 29. 

2 5 Assume that a device node A3 (108) shown in 

Fig. 1 is newly connected to the bus A by user 
operation in this network state. Since the new node is 
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additionally connected, bus reset occurs in accordance 
with IEEE 1394 characteristics. 

The 1394 interface layer of each node on the bus 
A which has received a bus reset signal notifies the 
5 upper protocol layer of this information. At the same 
time, the node starts a series of bus reset resume 
processes such as a bus reset sequence and node ID 
determination sequence in order to automatically assign 
a node ID upon occurrence of bus reset. 

10 After bus reset on the bus A 102 is notified to 

the DPP layer, the node Al (104), which establishes 
connection with the node Bl (106) on the bus B 103 in 
accordance with a DPP protocol on the bus A 102 and 
performs data transfer, starts bus reset resume 

15 processing complying with the DPP protocol. 

In bus reset resume processing by DPP, when data 
transfer normally restarts after bus reset resume 
processing ends in the 1394 layer to determine a new 
node ID and topology, a node which has first 

20 transmitted a connection request to a partner node 

within a predetermined time before data transmission 
restarts transmits a reconnection request command. 

After bus reset resume is completed in the 1394 
interface layer, a node which has received a request in 

25 establishment of connection enters a reception wait 

state for a reconnection request command from the node 
which has established connection. If the node does not 
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receive any command, it abandons the connection. 

After bus reset on the bus A 102 is notified to 
the AV/C layer, the node Bl (106) which is transferring 
data to the node B2 (107) on the bus B 103 in 
5 accordance with an AV/C protocol on the bus A 102 
starts bus reset procedure processing. 

In the AV/C protocol, a node which has received 
an AV/C command transmitted by one node generally 
transmits a paired response containing information such 

10 as command execution results and the like to the 

command issuing node. Upon occurrence of bus reset, an 
AV/C command sent before reset for which no response is 
received is regarded not to be executed and to be 
abandoned. Thus, an AV/C command must be resent after 

15 bus reset processing ends in the 1394 interface layer, 
and data transfer normally resumes. 

On the bus B 103 whose connection configuration 
is not changed, no bus reset occurs in accordance with 
the IEEE standard. Even if bus reset occurs on the bus 

20 A 102 connected via the 1394 bridge 101, the bus B 103 
detects this, but the 1394 bridge 101 does not 
propagate any bus reset signal to another bus, i.e., 
the bus B 103 in this case because of defined 
characteristics . 

25 Hence, only nodes such as the nodes Al, A2, and 

A3 connected to the bus A 102 start bus reset resume 
processing. The node Bl (106) as the data transmission 
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destination of the node Al (104) and the node B2 (107) 
as the data transmission destination of the node A2 
(105) do not start this processing. 

In the 1394 network system of the first 
5 embodiment, the 1394 bridge comprises a means for 

notifying, of bus reset occurrence information on one 
bus, a node connected to the other bus, and each node 
comprises a means for receiving a bus reset occurrence 
notification from a remote bus. 

10 More specifically, the 1394 bridge 101 which has 

received a bus reset signal upon occurrence of bus 
reset on the bus A executes bus reset processing on the 
node controller side. At the same time, the 1394 
bridge 101 notifies the node controller side of the bus 

15 B of occurrence of bus reset together with bus ID 
information of the bus A, i.e., a value 3FDh. 

The node controller of the bus B which has 
received this information uses a 1394 write transaction 
to write a packet containing data representing the bus 

20 ID: 3 FDh of the remote bus suffering bus reset in the 
register "REMOTE_BUS_RESET" arranged at address 0240 of 
each node connected to the bus B in accordance with the 
format of this register. 

Although no bus reset occurs on the bus B, the 

25 bus B is notified of occurrence of bus reset on the 
remote bus A by writing the ID of the bus A in the 
REMOTE_BUS_RESET register of each node by the 1394 
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bridge 101, as shown in (3) of Fig. 28 or (2) of Fig. 29. 

The 1394 interface layer of each node on the bus 
B which has detected write in the REMOT E_BU S_RE S ET 
register notifies the upper protocol layer of 
5 occurrence of bus reset on the remote bus and bus ID 
information of the remote bus. 

The node Bl, which has established connection 
with the node Al on the bus A in accordance with a DPP 
protocol on the bus B and has performed data transfer, 

10 checks the ID of the remote bus suffering bus reset, 

and confirms that the remote bus is the bus A connected 
to a node as the connection destination of the node Bl. 
Then, the node Bl recognizes that the connection 
destination node, i.e., node Al has started bus reset 

15 resume processing complying with a DPP protocol. 

The node Bl also starts processing corresponding 
to DPP bus reset processing, and enters a reception 
wait state for a reconnection request command from the 
node with which the node Bl establishes connection. 

20 This ensures the consistency of DPP protocol processing 
between the node Al which starts bus reset processing 
after bus reset actually occurs, and the node Bl 
connected to the bus B on which no bus reset occurs. 

After that, the node Al transmits a reconnection 

25 request command shown in © of Fig. 28 to the node Bl, 
and the node Bl transmits a reconnection request 
response shown in (5) of Fig. 28 to the node Al, thereby 
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restarting data communication. 

Similarly, the node B2, which has exchanged an 
AV/C command with the node A2 on the bus A in 
accordance with an AV/C protocol on the bus B, checks 
5 the ID of the remote bus suffering bus reset, and 

confirms that the remote bus is the bus A connected to 
the node A2 as a connection destination node. Then, 
the node B2 recognizes that the connection destination 
node, i.e., node A2 has started bus reset processing 

10 according to an AV/C protocol. 

The node B2 also executes processing 
corresponding to AV/C bus reset processing shown in 
Fig. 29, and processing in which an AV/C command sent 
before remote bus reset for which no response is 

15 received is regarded not to be executed and to be 
abandoned. This ensures the consistency of AV/C 
protocol processing between the node A2 which starts 
bus reset processing after bus reset actually occurs, 
and the node B2 connected to the bus B on which no bus 

20 reset occurs. 

The node B2 resends an AV/C command shown in (3) 
of Fig. 29 to the node A2 . In response to this, the 
node A2 transmits an AV/C response shown in © of 
Fig. 29 to the node B2, thereby continuing 

2 5 communication. 

As described above, the first embodiment provides 
a 1394 bus system characterized in that a node 
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connected to an IEEE 1394 bus comprises a means capable 
of receiving the ID of a bus suffering bus reset and a 
reset occurrence notification when bus reset occurs on 
a remote bus other than a bus connected to the self 
5 node, and if a plurality of buses are connected via 
bridges, a bridge connected to the bus suffering bus 
reset transmits to the reception means of other 
connected buses a remote bus reset occurrence 
notification containing the ID of the bus suffering bus 

10 reset. When bus reset occurs on one local bus in 

performing data transfer from a data transmission node 
on one local bus to a data reception node connected to 
the other local bus via a 1394 bridge, the 1394 bridge 
can notify the node connected to the remote bus of bus 

15 reset. The reception node connected to the other bus 

can detect bus reset to maintain the consistency of bus 
reset processing in the upper protocol layer. This 
enables normal data communication between buses. 

The first embodiment can further provide a node 

20 connected to an IEEE 1394-compliant communication 

control bus with a means capable of receiving the ID of 
a bus suffering bus reset and a reset occurrence 
notification when bus reset occurs on a remote bus 
other than a local bus connected to the self node. 

25 As the remote bus reset occurrence notification 

reception means, the first embodiment can provide a 
means for storing a register at a predetermined address 
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on the node, and detecting write of bus ID information 
at the address to receive a remote bus reset occurrence 
notification . 

Further, the first embodiment can provide an 
5 information signal processing apparatus characterized 
in that the predetermined register is arranged in the 
core CSR architecture register space or serial bus 
register space in the address space of each 1394 node. 
The first embodiment can provide a 1394 bus 

10 system characterized in that occurrence of remote bus 
reset is notified when a plurality of buses are 
connected via bridges in an IEEE 1394 bus system, and 
bus reset occurs in a remote bus other than connected 
buses. Moreover, this embodiment can provide a 1394 

15 bus system characterized in that a bridge connected to 
a bus suffering bus reset transmits to the node of 
another connected bus a remote bus reset occurrence 
notification containing the ID of the bus suffering bus 
reset . 

20 [Second Embodiment] 

The second embodiment according to the present 
invention will be described below. In the second 
embodiment, the configuration and function of a 
communication system using a 1394 interface are the 
25 same as those in the first embodiment, and a detailed 
description thereof will be omitted. 

In the second embodiment, the same reference 
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numerals as in the first embodiment denote the same 
parts in the configuration and connection device of the 
second embodiment, and a detailed description thereof 
will be omitted. 
5 In the second .embodiment, a 1394 serial bus 

interface can be constituted similarly to the first 
embodiment shown in Fig. 23, and the configuration ROM 
of each node can adopt the same formats as those shown 
in Figs. 24 and 25. The second embodiment is different 

10 from the first embodiment in that the format of an area 
from address 0200 to address 0400 shown in Fig. 25 for 
storing serial bus dependent registers has the format 
shown in Fig. 30. 

In the second embodiment, NOT I FY_BUS_RESET 

15 arranged at address 0244 is assigned in addition to 

serial bus dependent registers shown in Fig. 26, and is 
a characteristic register of the second embodiment. 
The format of the NOT I FY_BUS_RESET register will be 
explained with reference to Fig. 31. Fig. 31 is a view 

20 showing the format of the NOT I FY_BU S_RE SET register in 
the second embodiment. 

The NOTIFY_BUS_RESET register is a register 
mounted on the bridge portal of a 1394 bridge 101 (to 
be described below) to which the second embodiment is 

25 applied. According to a 1394 write transaction, a data 
with a format of Fig. 31 is written into the register. 
If an effective bus ID, an effective node ID and an 
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effective command (1: store, 0: delete) are 
respectively substituted in a BUS_ID field, a NODE_ID 
field and a command field of the data written in the 
register, the bridge 101 receives the data as an 
5 effective data, and executes process according to the 
value of the command field. If the value of the 
command field is "1" (store) , the bridge 101 stores the 
values of BUS_ID field and NODE_ID field of the 
received data into the storage table corresponds to the 

10 portal. If the value of the command field is "0" 

(delete) , the bridge 101 deletes the values of BUS_ID 
field and NODE_ID field of the received data from the 
storage table corresponds to the portal. When a bus 
reset occurs in the 1394 bus to which the portal is 

15 connected, the bridge 101 notifies the occurrence of 

the bus reset to the node by writing, according to the 
1394 write transaction, to a REMOT E_BU S_RE S ET register 
of the node designated by the bus ID and node ID stored 
in the storage table. 

20 Fig. 32 is a block diagram showing the 

arrangement of the IEEE 1394 bridge 101 in the second 
embodiment. In Fig. 32, a portal A 3301 is connected 
to a bus A 102, whereas a portal B 3302 is connected to 
a bus B 103. Each portal functions as one node 

25 connected to the bus. 

A bridge controller 3303 has a function of 
bridging the portals A 3301 and B 3302. A bus reset 
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manager 3304 stores or deletes a bus ID and node ID 
written in the NOTIFY_BUS_RESET register of the portal 
A 3301 in or from a storage table A 3305. 

Similarly, the bridge controller 3303 stores or 
5 deletes a bus ID and node ID written in the 

NOTIFY_BUS_RESET register of the portal B 3302 in or 
from a storage table B 3306. The bridge controller 
3303 notifies a node of occurrence of bus reset by 
writing data in accordance with the same format of 

10 Fig. 27 as in the first embodiment in the 

REMOTE_BUS_RESET register of the node stored in the 
storage table A 3305 when bus reset occurs on the bus A 
102, or in the storage table B 3306 when bus reset 
occurs on the bus B 103. 

15 The configuration ROM is arranged in an area from 

address 0400 to address 0800. 

Similar to the first embodiment, an area from 
address 0800 to address 1000 shown in Fig. 25 stores 
the current 1394 bus topology information and 

20 information about the transfer speed between nodes. An 
area after address 1000 is called a unit space where 
registers concerning operations unique to each device 
are arranged. This area stores registers and a data 
transfer memory mapped buffer area defined by upper 

25 protocols supported by each device, or device dependent 
registers . 

A detailed operation in a 1394 network shown in 



Fig. 1 where the nodes Al (104) and A2 (105) each 
having a 1394 interface constituted in the above manner 
are connected to the bus A 102,. the nodes Bl (106) and 
B2 (107) are connected to the bus B 103, and the bus A 
5 102 and bus B 103 are connected by the 1394 bridge 101 
will be explained with reference to Figs. 33 and 34. 
Fig. 33 is a view showing communication control 
procedures complying with a DPP protocol in the second 
embodiment, and Fig. 34 is a view showing communication 

10 control procedures complying with an AV/C protocol in 
the second embodiment. 

Before buses A and B attain their current 
connection configurations, bus reset independently 
occurs on each bus every time a device node is 

15 additionally connected. Upon occurrence of bus reset, 
a node ID is automatically assigned. For this purpose, 
a bus reset seguence and bus ID determination seguence 
are executed to create a new topology. 

Then, 1394 data transfer starts on each bus. 

20 Details of these seguences are described in "(6) 

Description of Seguence After Occurrence of Bus Reset" 
and "(8) Assignment of Node ID" of <Technical Overview 
of IEEE 1394 Standard>, and a description thereof will 
be omitted. 

2 5 Although the operation changes depending on the 

connection order of connection nodes and the connection 
order of buses to the 1394 bridge 101, the bus 
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reset-1394 initialization sequence is repeated every 
time a node is connected. Finally, a topology in which 
devices Al and A2 are connected to the bus A via the 
1394 bridge 101, and devices Bl and B2 are connected to 
5 the bus B is formed. 

While the topology of the 1394 network is 
determined in this state, and 1394 data transfer is 
normally performed, the node Al as a digital still 
camera having a direct print protocol (to be referred 

10 to as a "DPP") as an upper protocol searches for a 
printer device which supports the DPP on the 1394 
network, like the self node, in order to transfer image 
data to a printer connected to the 1394 network and 
print the image data in accordance with user operation 

15 or the trigger of an application. 

This is realized by read-accessing the 
configuration ROM of a partner node for a node 
connected to the network. This is shown in Fig. 19. 
More specifically, the node uses an IEEE 1394 read 

20 transaction for the partner node to receive the ROM 
contents of the partner node as a read response. 

As described above, 1394-related information is 
described in the configuration ROM of each node. 
Further, the basic function of each node such as a 

25 printer or camera is described in the instance 

directory, and an upper protocol such as an AV/C 
protocol or DPP and software information are described 
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in the unit directory. 

While the node Al read-accesses the ROM of each 
node on the local bus A, and then read-accesses the ROM 
of each node on the bus B via the 1394 bridge, the node 
5 Al detects that the node Bl is a printer as a DPP 
device . 

Although details of a 1394 transaction via the 
1394 bridge will be omitted, its standard is being 
defined by IEEE pl394.1. 

10 After the camera as the node Al (104) finds the 

node Bl (106) which is a printer and has the same 
protocol as the DPP protocol supported by the node Al, 
the node Al establishes connection with the node Bl in 
accordance with procedures and a format defined by the 

15 DPP protocol shown in Fig. 33, and starts data transfer. 

At this time, as shown in GD of Fig. 33, the node 
Al (104) writes { (bus ID of bus B) , (node ID of node 
Bl) , (storage command)} in the NOT I FY_BUS_RESET 
register of the portal A 3301 of the 1394 bridge 101 in 

20 accordance with the format shown in Fig. 31. The node 
Al (104) transmits a connection request command to the 
node Bl using a write transaction shown in (2) of 
Fig. 33. 

In response to this, as shown in (3) of Fig. 33, 
25 the node Bl (106) writes {(bus ID of bus A), (node ID 

of node Al) , (storage command)} in the NOTIFY_BUS_RESET 
register of the portal B 3302 of the 1394 bridge 101 in 
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accordance with the format of Fig. 31. 

The node Bl (106) transmits a connection request 
response to the node Al using a write transaction shown 
in © of Fig. 33. In this way, the node Al (104) 
5 establishes connection with the node Bl (106), and the 
bus reset manager of the 1394 bridge stores these bus 
IDs and node IDs in corresponding storage tables. 

Similarly, the node B2 (107) as a digital video 
cam coder having an AV/C protocol as an upper protocol 
10 starts transmission/reception of an AV/C command with 
the node A2 (105) via the 1394 bridge using an AV/C 
protocol. For this purpose, the node B2 (107) performs 
the same write operation as © of Fig. 33 in the bridge 
101 so as to enable notifying a partner node of bus 
15 reset, as shown in ® of Fig. 34. 

The node B2 (107) issues an AV/C command shown in 
(2) of Fig. 34, and enters a response wait state. Also, 
the node A2 (105) which has received the AV/C command 
shown in (2) of Fig. 34 performs the same write 
20 operation as (3) of Fig. 33 in the bridge 101 so as to 

enable notifying a partner node of bus reset, as shown 
in (3) of Fig. 34. 

Assume that a device node A3 (108) shown in 
Fig. 1 is newly connected to the bus A by user 
25 operation in this network state. Then, bus reset 

occurs in accordance with IEEE 1394 characteristics. 

In this case, no bus reset occurs on the bus B 



103 whose connection configuration does not change. 
The node Bl (106) serving as the data transmission 
destination of the node Al (104), and the node B2 (107) 
serving as the data transmission destination of the 
5 node A2 (105) do not start bus reset resume processing. 

However, this causes the above problem, so that 
the second embodiment executes the following operation 
instead of the defined operation. 

In the 1394 network system of the second 

10 embodiment, the bus reset manager 3304 of the 1394 
bridge 101 comprises a means for notifying, of bus 
reset occurrence information on a bus connected to a 
bridge portal, a node stored in a storage table 
corresponding to this portal. Each node comprises a 

15 means for receiving a sub reset occurrence notification 
on a remote bus. This arrangement solves the above 
problem. 

More specifically, the 1394 bridge 101 which has 
received a bus reset signal upon occurrence of bus 

20 reset on the bus A 102 performs bus reset processing by 
the node controller of the portal A 3301 connected to 
the bus A 102. The bus reset manager 3304 uses a 1394 
write transaction to sequentially write packets 
containing data of the bus ID of a remote bus, i.e., 

25 the bus ID: 3FDh of the bus A suffering bus reset in 
accordance with the register format in the 
REMOTE_BUS_RESET registers arranged at address 0240 of 



69 



the serial bus registers of respective nodes shown in 
Fig. 30 that are stored in the storage tables 3305 and 
3306. 

In the second embodiment, the bus IDs and node 
5 IDs of the node Bl (106) and node B2 (107) are stored 
In the storage tables, so that data are written in 
these nodes, as shown in (5) of Fig. 33 or © of Fig. 34. 

As a result, the bus B 103 does not suffer bus 
reset, but can be notified of occurrence of bus reset 
10 on the remote bus A by writing the ID of the bus A 102 
in the R EMOT E_B U S_RE SET register of each node that 
should be notified by the bridge 101. 

The 1394 interface layer of each node which has 
detected write in the REMOTE_BQS_RESET register 
15 notifies the upper protocol layer of occurrence of bus 
reset on a remote bus and the bus ID information of the 
remote bus. 

The node Bl (106), which establishes connection 
with the node Al (104) on the bus A in accordance with 

20 a DPP protocol on the bus B and performs data transfer, 
checks the ID of the remote bus suffering bus reset, 
and confirms that the remote bus is the bus A 102 
connected to a node as the connection destination of 
the node Bl. Then, the node Bl recognizes that the 

25 connection destination node, i.e., node Al (104) has 
started bus reset resume processing complying with a 
DPP protocol. 
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The node Bl {106) also starts processing 
corresponding to DPP bus reset processing, and enters a 
reception wait state for a reconnection request command 
from the node with which the node Bl (106) establishes 
5 connection. This ensures the consistency of DPP 

protocol processing between the node Al (104) which 
starts bus reset processing after bus reset actually 
occurs, and the node Bl (106) connected to the bus B 
103 on which no bus reset occurs. 

10 After that, the node Al (104) transmits a 

reconnection request command shown in (6) of Fig. 33 to 
the node Bl (106), and the node Bl (106) transmits a 
reconnection request response shown in © of Fig. 33 to 
the node Al (104), thereby restarting data 

15 communication. 

Similarly, the node B2 (107), which exchanges an 
AV/C command with the node A2 (105) on the bus A 102 in 
accordance with an AV/C protocol on the bus B 103, 
checks the ID of the remote bus suffering bus reset, 

20 and confirms that the remote bus is the bus A 102 
connected to the node A2 (105) as the connection 
destination of the node B2 . Then, the node B2 (107) 
recognizes that the connection destination node, i.e., 
node A2 (105) has started bus reset processing 

25 according to an AV/C protocol. The node B2 (107) also 
executes processing corresponding to AV/C bus reset 
processing, and processing in which an AV/C command 
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sent before remote bus reset for which no response is 
received is regarded not to be executed and to be 
abandoned. This ensures the consistency of AV/C 
protocol processing between the node A2 (105) which 
5 starts bus reset processing after bus reset actually 
occurs, and the node B2 (107) connected to the bus B 
103 on which no bus reset occurs. 

The node B2 (107) resends an AV/C command shown 
in (5) of Fig. 34 to the node A2 (105) . In response to 

10 this, the node A2 (105) transmits an AV/C response 

shown in © of Fig. 34 to the node B2 (107), thereby 
continuing communication. 

Even when bus reset occurs on the bus B 103, the 
bus reset manager 3304 of the 1394 bridge 101 similarly 

15 notifies a target node on the bus A 102 of occurrence 
of bus reset, thereby maintaining the consistency of 
upper protocol processing. 

As described above, the second embodiment 
provides an IEEE 1394 bridge having at least two 

20 portals respectively connected to different IEEE 1394 
buses, characterized by comprising a bus reset 
management means made up of a means for monitoring bus 
reset of the IEEE 1394 buses inserted/removed to/from 
the respective portals, a means for designating either 

25 one of the IEEE 1394 buses connected to the respective 
portals, a means for designating a node on a network 
constituted by a plurality of IEEE 1394 buses connected 
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via bridges, and a means for notifying the designated 
node of bus reset of the designated bus. This IEEE 
1394 bridge can notify a node connected to a remote bus 
of occurrence of bus reset. 
5 [Third Embodiment] 

In the third embodiment, the basic configuration 
is the same as in the first and second embodiments 
shown in Figs. 1 to 34, and a detailed description 
thereof will be omitted. Only the difference from the 

10 first and second embodiments will be described. The 
third embodiment is different from the second 
embodiment in communication control procedures 
complying with a DPP protocol. Communication control 
procedures complying with a DPP protocol in the third 

15 embodiment according to the present invention will be 
described with reference to Fig. 35. 

Similar to the second embodiment, while the 
topology of a 1394 network is determined, and 1394 data 
transfer is normally performed, a node Al as a digital 

20 still camera having a DPP as an upper protocol searches 
for a printer device which supports the DPP on the 1394 
network, like the self node, in order to transfer image 
data to a printer connected to the 1394 network and 
print the image data in accordance with user operation 

25 or the trigger of an application. 

While the node Al read-accesses the ROM of each 
node on a local bus A 102, and then read-accesses the 
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ROM of each node on a bus B 103 via a 1394 bridge, the 
node Al detects that a node Bl is a printer as a DPP 
device. Assume that the node Bl comprises a 
REMOTE_BUS_RESET register, but the node Al does not 
5 comprise it. The node Bl can know this from ROM 
information of the node Al . 

In the third embodiment, when (3FFH) and (3FH) 
are respectively written in the bus ID field and node 
ID field of the format shown in Fig. 31 in the 

10 NOTIFY_BUS_RESET register of a bridge portal, a bus 

reset manager 3304 of a 1394 bridge 101 stores the bus 
ID and node ID of the writing node in a storage table 
corresponding to the written portal. 

After the camera as the node Al finds the node Bl 

15 which is a printer and has the same protocol as the DPP 
protocol supported by the node Al, the node Al 
establishes connection with the node Bl in accordance 
with procedures and a format defined by the DPP 
protocol. To start transferring application data, the 

20 node Al transmits a connection request shown in CD of 
Fig. 35 to the node Bl using a write transaction. 

At this time, as shown in (2) of Fig. 35, the node 
Bl writes { (3FFH) , (3FFH), (storage command)} in the 
NOT I FY_BUS_RESET register of the portal A 3301 of the 

25 1394 bridge in accordance with the format of Fig. 31. 

The bus reset manager of the 1394 bridge stores 
the bus ID and node ID of the node Bl in a storage 



table corresponding to the portal A. Then, the node Bl 
transmits a connection request response shown in (3) of 
Fig. 35 to the node Al using a write transaction, and 
establishes connection. 
5 Similar to the second embodiment, assume that a 

device node A3 (108 shown in Fig. 1) is newly connected 
to the bus A 102 by user operation in the network state 
shown in Fig. 1. Part of this control is different 
from the second embodiment. 

10 Since the new node is additionally connected, bus 

reset occurs in accordance with IEEE 1394 
characteristics. The 1394 interface layer of each node 
on the bus A 102 which has received a bus reset signal 
notifies the upper protocol layer of this information. 

15 At the same time, the node starts a series of bus reset 
resume processes such as a bus reset sequence and node 
ID determination sequence in order to automatically 
assign a node ID upon occurrence of bus reset. 

After bus reset on the bus A 102 is notified to 

20 the DPP layer, the node Al (104), which has established 
connection with the node Bl (106) on the bus B 103 in 
accordance with a DPP protocol on the bus A 102 and has 
performed data transfer, starts bus reset resume 
processing complying with the DPP protocol, similar to 

25 the first embodiment. 

On the other hand, when no bus reset occurs in 
the bus B 103 whose connection configuration does not 
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change, and bus reset occurs on the bus A 102, as 
described in the first embodiment, a bus reset signal 
is not propagated to the bus B 103. At this time, only 
nodes such as the nodes Al, A2, and A3 connected to the 
5 bus A start bus reset resume processing. The node Bl 

as the data transmission destination of the node Al and 
the node B2 as the data transmission destination of the 
node A2 do not start this processing. 

In the third embodiment, as well as the first 

10 embodiment, the 1394 bridge 101 which has received a 
bus reset signal upon occurrence of bus reset on the 
bus A 102 executes bus reset processing on the node 
controller side of the portal A 3301 connected to the 
bus A 102. The bus reset manager 3304 uses a 1394 

15 write transaction to sequentially write packets 

containing data of the bus ID of a remote bus, i.e., 
the bus ID: 3FDh of the bus A 102 suffering bus reset 
in accordance with the register format in 
REMOT E_B U S_R E S E T registers arranged at address 0240 of 

20 respective nodes stored in storage tables 3305 and 3306. 
At the same time, the bus reset manager 3304 also 
writes data in the node Bl, as shown in (4) of Fig. 35. 

Although no bus reset occurs on the bus B, the 
bus B is notified of occurrence of bus reset on the 

25 remote bus A by writing the ID of the bus A 102 in the 
REMOTE_BU S_RE S ET register of each target node by the 
1394 bridge 101. 
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The 1394 interface layer of each node which has 
detected write in the REMOTE_BUS_RESET register 
notifies the upper protocol layer of occurrence of bus 
reset on the remote bus and bus ID information of the 
5 remote bus . 

The node Bl (106) , which has established 
connection with the node Al (104) on the bus A 102 in 
accordance with a DPP protocol on the bus B 103 and has 
performed data transfer, checks the ID of the remote 

10 bus suffering bus reset, and confirms that the remote 
bus is the bus A connected to a node as the connection 
destination of the node Bl (106) . Then, the node Bl 
(10 6) recognizes that the connection destination node, 
i.e., node Al (104) has started bus reset resume 

15 processing complying with a DPP protocol. 

The node Bl (106) also starts processing 
corresponding to DPP bus reset processing, and enters a 
reception wait state for a reconnection request command 
from the node with which the node Bl (106) establishes 

20 connection. This ensures the consistency of DPP 

protocol processing between the node Al which starts 
bus reset processing after bus reset actually occurs, 
and the node Bl connected to the bus B on which no bus 
reset occurs. 

25 Thereafter, the node Al transmits a reconnection 

request command shown in (D of Fig. 35 to the node Bl, 
and the node Bl transmits a reconnection request 
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response shown in (6) of Fig. 35 to the node Al, thereby- 
restarting data communication. 

If bus reset occurs on the bus B, the node Al on 
the bus A does not know occurrence of bus reset on the 
5 bus B. During bus reset on the bus B, the request of 
the node Al is held by the bridge, and sent to the node 
Bl by the bridge after the end of bus reset on the bus 
B, as shown in (7) of Fig. 35. The node Bl transmits a 
reconnection request response to the node Al, as shown 

10 in (8) of Fig. 35, and can restart data communication. 

Since the node Bl can maintain consistency after 
the end of bus reset, the node Bl can restart 
communication in response to a request from the node Al, 
as shown in Fig. 35. 

15 As described above, the third embodiment provides 

an information communication system including a first 
IEEE 1394 bus connected to an IEEE 1394 bridge, a first 
node connected to the first IEEE 1394 bus, a second 
IEEE 1394 bus different from the first IEEE 1394 bus, 

20 and a second node connected to the second IEEE 1394 bus, 
the first and second nodes communicating with each 
other, characterized in that the first node instructs 
the IEEE 1394 bridge connected to the first IEEE 1394 
bus to monitor bus reset on the first IEEE 1394 bus and 

25 notify the second node of bus reset on the first IEEE 
1394 bus. This information communication system can 
notify a communication partner node connected to a 
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remote bus of occurrence of bus reset on a bus 
connected to the self node. 

If bus reset occurs on one local bus in 
performing data transfer from a data transmission node 
5 on one local bus to a data reception node connected to 
the other local bus via a 1394 bridge using the same 
upper protocol, the 1394 bridge can notify the node 
connected to the remote bus of bus reset. The 
reception node connected to the other bus can detect 
10 the bus reset, and maintain the consistency of bus 
reset processing in the upper protocol layer. This 
enables normal data communication between buses. 
[Fourth Embodiment] 

Fig. 36 is a block diagram showing the 
15 configuration of the fourth embodiment according to the 
present invention. 

In the fourth embodiment, as shown in Fig. 36, a 
1394 bridge A 3401 is connected to a bus A via a portal 
A, and to a bus C via a portal CI. A 1394 bridge B 
20 3402 is connected to a bus B via a portal B, and the 
bus C via a portal C2 . 

The bus A is connected to a node Al (3403) and 
node A2 (3404), the bus B is connected to a node Bl 
(3405) and node B2 (3406), and the bus C is connected 
25 to a node CI (3407) and node C2 (3408) . 

The bus A has a bus ID (3FDh), the bus B has a 
bus ID (3FEh), and the bus C has a bus ID (3FCh) . 
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The system of the fourth embodiment has the same 
building components as those in the third embodiment, 
and the 1394 bridge has the same arrangement as that 
shown in Fig. 32. Only the difference from the third 
5 embodiment will be described below. 

In the fourth embodiment, as well as the second 
embodiment, after a camera as the node Al finds the 
node Bl which is a printer and has the same protocol as 
the DPP protocol supported by the node Al, the node Al 

10 establishes connection with the node Bl in accordance 
with the procedures and format defined by a DPP 
protocol shown in Fig. 37, and starts transferring 
application data. As shown in ® of Fig. 37, the node 
Al writes {(bus ID of bus B) , (node ID of node Bl), 

15 (storage command) } in the NOTIFY_BUS_RESET register of 
the portal A of the 1394 bridge A 3401, and transmits 
a connection request shown in (2) of Fig. 37 to the node 
Bl. In response to this, as shown in (E> of Fig. 37, the 
node Bl writes {(bus ID of bus A), (node ID of node Al) , 

20 (storage command) } in the NOT I F Y_B U S_RE SET register of 
the portal B of the second 1394 bridge in accordance 
with the format of Fig. 31, and transmits a connection 
request shown in © of Fig. 37 to the node Al . 

The bus reset managers of the 1394 bridges A3401 

25 and B3402 store these bus IDs and node IDs in 
corresponding storage tables. 

Similarly, the node B2 as a digital video cam 
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coder having an AV/C protocol as an upper protocol 
starts exchanging an AV/C command with the node A2 via 
the 1394 bridges A 3401 and B 3402 using an AV/C 
protocol. The node B2 performs the same write 
5 operation as © of Fig. 37 in the second 1394 bridge in 
(D of Fig. 38 so as to enable notifying a partner node 
of bus reset. Subsequently, the node B2 issues an AV/C 
command, as shown in (2) of Fig. 38, and enters a 
response wait state. 
10 The node A2 which has received the command from 

the node B2 performs the same write operation as ® of 
Fig. 38 in the first 1394 bridge so as to enable 
notifying a partner node of bus reset, as shown in © 
of Fig. 38. 

15 Assume that a device node A3 (3409 in Fig. 36) is 

newly connected to the bus A by user operation in this 
network state. Since the new node is additionally 
connected, bus reset occurs in accordance with IEEE 
1394 characteristics. The 1394 interface layer of each 

20 node on the bus A which has received a bus reset signal 
notifies the upper protocol layer of this information. 
At the same time, the node starts a series of bus reset 
resume processes such as a bus reset sequence and node 
ID determination sequence in order to automatically 

25 assign a node ID upon occurrence of bus reset. 

In the fourth embodiment, as well as the first 
embodiment, the 1394 bridge A 3401 which has received a 
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bus reset signal upon occurrence of bus reset on the 
bus A executes bus reset processing on the node 
controller side of the portal A connected to the bus A. 
The bus reset manager uses a 1394 write transaction to 
5 sequentially write packets containing data of the bus 
ID of a remote bus, i.e., the bus ID: 3FDh of the bus A 
suffering bus reset in accordance with the register 
format in REMOTE_BUS_RESET registers arranged at 
address 0240 of respective nodes stored in the storage 
10 tables, as shown in © of Fig. 37 or @ of Fig. 38. 

These packets are transmitted to the node on the 
bus B via the bus C and the 1394 bridge B 3402. 

Although no bus reset occurs on the bus B, the 
bus B is notified of occurrence of bus reset on the 
15 remote bus A by writing the ID of the bus A in the 

REMOTE_BUS_RESET register of each node which should be 
notified to the storage table of the 1394 bridge B 3402. 

The 1394 interface layer of each node which has 
detected write in the REMOT E_B U S_RES ET register 
20 notifies the upper protocol layer of occurrence of bus 
reset on the remote bus and bus ID information of the 
remote bus . 

Similar to the first embodiment, each node 
performs processing corresponding to bus reset to 
25 ensure the consistency of an upper protocol, as shown 
in © and © of Fig. 37 or © and © of Fig. 38. 

Bus reset on the bus B can also be notified from 
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the 1394 bridge B 3402 to the node on the bus A via the 
bus C and 1394 bridge A 3401, thereby maintaining the 
consistency of an upper protocol. 

As described above, according to the fourth 
5 embodiment, a notification packet is transmitted to 
only a node to which bus reset must be notified. The 
traffic on the network does not greatly increase, and 
the performance of the network does not decrease. 

The fourth embodiment provides an information 

10 communication system including a first IEEE 1394 bus 
connected to an IEEE 1394 bridge, a first node 
connected to the first IEEE 1394 bus, a second IEEE 
1394 bus different from the first IEEE 1394 bus, and a 
second node connected to the second IEEE 1394 bus, the 

15 first and second nodes communicating with each other, 
characterized in that the second node instructs the 
IEEE 1394 bridge connected to the first IEEE 1394 bus 
to monitor bus reset on the first IEEE 1394 bus and 
notify the second node of bus reset on the first IEEE 

20 1394 bus. This information communication system can 
notify the self node connected to a remote bus of 
occurrence of bus reset on a bus connected to a 
connection partner. Since the self node comprises an 
ability of maintaining consistency against bus reset on 

25 the remote bus, the node can communicate with a 

conventional device which is connected to the remote 
bus and to which the present invention is not applied. 
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[Fifth Embodiment] 

In the fifth embodiment, the same reference 
numerals as in the second embodiment denote the same 
parts of the configuration and connection device in the 
5 fifth embodiment, and a detailed description thereof 
will be omitted. 

In the fifth embodiment, similar to the first 
embodiment, the 1394 serial bus interface has the same 
arrangement as in the first embodiment shown in Fig. 23, 

10 and the configuration ROM of each node has the same 

format as shown in Figs. 24 and 25. Further, an IEEE 
1394 bridge device 101 has the same arrangement as in 
the second embodiment shown in Fig. 32. 

The fifth embodiment is different from the above 

15 embodiments in that the format of an area where serial 
bus dependent registers from address 0200 to address 
0400 shown in Fig. 25 has the format shown in Fig. 39. 

The fifth embodiment uses address 023C, and does 
not require an area from address 0240, compared to the 

20 serial bus dependent registers shown in Figs. 26 and 30. 
That is, the fifth embodiment is characterized by an 
operation with defined registers at address 0200 to 
address 0230 described in technical Overview of IEEE 
1394 Standard>. The operation in the fifth embodiment 

25 adopting the 1394 bridge 101 with the same arrangement 
shown in Fig. 32 as the second embodiment will be 
described with reference to Figs. 40 and 41. 
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Fig. 4 0 is a view showing communication control 
procedures complying with a direct print protocol (to 
be referred to as a " DPP" hereinafter) in the fifth 
embodiment according to the present invention. Fig. 41 
is a view showing communication control procedures 
complying with an AV/C protocol in the fifth embodiment. 

Before buses A and B attain their current 
connection configurations, bus reset independently 
occurs on each bus every time a device node is 
additionally connected. A bus reset sequence and bus 
ID determination sequence are executed to automatically 
assign a node ID upon occurrence of bus reset, and a 
new topology is created. 

Then, 1394 data transfer starts on each bus. 
Details of these sequences are described in "(6) 
Description of Sequence After Occurrence of Bus Reset" 
and "(8) Assignment of Node ID" of <Technical Overview 
of IEEE 1394 Standards and a description thereof will 
be omitted. 

Although the operation changes depending on the 
connection order of connection nodes and the connection 
order of buses to the 1394 bridge, the bus reset-1394 
initialization sequence is repeated every time a node 
is connected. Finally, a topology in which devices Al 
and A2 are connected to the bus A via the 1394 bridge 
101, and devices Bl and B2 are connected to the bus B 
is formed. 
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While the topology of the 1394 network is 
determined in this state, and 1394 data transfer is 
normally performed, the node Al as a digital still 
camera having a DPP as an upper protocol searches for a 
5 printer device which supports the DPP on the 1394 

network, like the self node, in order to transfer image 
data to a printer connected to the 1394 network and 
print the image data in accordance with user operation 
or the trigger of an application. 

10 This is realized by read-accessing the 

configuration ROM of a partner node for a node 
connected to the network. This is described in the 
first embodiment with reference to Fig. 19. More 
specifically, the node uses an IEEE 1394 read 

15 transaction for the partner node to receive the ROM 
contents of the partner node as a read response. 

As described above, 1394-related information is 
described in the configuration ROM of each node. 
Further, the basic function of each node such as a 

20 printer or camera is described in the instance 

directory, and an upper protocol such as an AV/C 
protocol or DPP and software information are described 
in the unit directory. 

While the node Al read-accesses the ROM of each 

25 node on the local bus A, and then read-accesses the ROM 
of each node on the bus B via the 1394 bridge, the node 
Al detects that the node Bl is a printer as a DPP 
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device . 

Although details of a 1394 transaction via the 
1394 bridge will be omitted, its standard is being 
defined by IEEE pl394.1. 
5 After the camera as the node Al finds the node Bl 

which is a printer and has the same protocol as the DPP 
protocol shown in Fig. 40 that is supported by the node 
Al, the node Al establishes connection with the node Bl 
in accordance with procedures and a format defined by 
10 the DPP protocol. 

More specifically, the node Al transmits a 
connection request command to the node Bl using a write 
transaction, as shown in ® of Fig. 40. In response to 
this, the node Bl transmits a connection request 
15 response shown in (D of Fig. 40 to the node Al . 

At this time, the 1394 bridge 101 traces 
communication between these nodes, and stores an 
identification set of the bus ID and node ID of the 
node Bl, those of the node Al, and the DPP protocol in 
20 a connection management table 3105. 

Similarly, the node B2 as a digital video cam 
coder having an AV/C protocol as an upper protocol 
starts transmission/reception of an AV/C command with 
the node A2 shown in Fig. 41 via the 1394 bridge using 
25 an AV/C protocol. The node B2 issues an AV/C command 
shown in ® of Fig. 41, and enters a response wait 
state . 
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The 1394 bridge 101 traces communication between 
these nodes, and stores an identification set of the 
bus ID and node ID of the node B2, those of the node A2, 
and the AV/C protocol in the connection management 
5 table 3105. 

Assume that a device node A3 (node 108 shown in 
Fig. 1) is newly connected to the bus A by user 
operation in this network state. Then, bus reset 
occurs, as described above, and a series of bus reset 

10 resume processes start. When bus reset on the bus A is 
notified to the DPP layer, the node Al, which has 
established connection with the node Bl on the bus B in 
accordance with a DPP protocol on the bus A and has 
performed data transfer, starts the above-described bus 

15 reset resume processing complying with the DPP protocol. 

On the bus B whose connection configuration is 
not changed, no bus reset occurs. If bus reset occurs 
on the bus A connected via the 1394 bridge 101, the bus 
B detects this, but the characteristics of the 1394 

20 bridge 101 in the fifth embodiment prevent any bus 

reset signal from propagating to another bus, i.e., the 
bus B in this case. 

Hence, only nodes such as the nodes Al, A2, and 
A3 connected to the bus A start bus reset resume 

25 processing. The node Bl as the data transmission 

destination of the node Al and the node B2 as the data 
transmission destination of the node A2 do not start 



this processing. 

In the 1394 network system of the fifth 
embodiment, the 1394 bridge 101 comprises a means for 
storing connection information containing the upper 
5 protocol of a node which establishes connection via the 
bridge, and performing, by the bridge, bus reset resume 
processing of the upper protocol layer which should be 
executed by a node connected to the other node upon 
occurrence of bus reset on one bus. 

10 More specifically, the 1394 bridge 101 which has 

received a bus reset signal upon occurrence of bus 
reset on the bus A executes bus reset processing on the 
node controller side connected to the bus A. At the 
same time, the 1394 bridge 101 confirms a node on the 

15 bus A which starts bus reset resume processing of the 
upper protocol layer, from connection information 
stored in the connection management table. 

The node Al of the bus A transmits a reconnection 
command shown in (D of Fig. 4 0 to the node Bl with 

20 which the node Al establishes connection to transfer 
data. The 1394 bridge does not transmit this to the 
node Bl, but transmits a reconnection response shown in 
© of Fig. 40 to the node Al in place of the node Bl. 
This ensures the consistency of DPP protocol processing 

25 between the node Al which starts bus reset processing 
after bus reset actually occurs, and the node Bl 
connected to the bus B on which no bus reset occurs. 
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The node B2, which has exchanged an AV/C command 
with the node A2 on the bus A in accordance with an 
AV/C protocol on the bus B, wait for a response from 
the node A2 . However, the communication destination 
5 node A2 starts bus reset processing complying with an 
AV/C protocol, and abandons the command received from 
the node B2 because bus reset has occurred on the 
connected bus A. The 1394 bridge knows that a response 
from the node A2 is not transmitted to the node B2 . 
10 Thus, the 1394 bridge resends an AV/C command which the 
node B2 sent before remote bus reset and for which no 
response is received, to the node A2, as shown in (2) of 
Fig. 41. 

This ensures the consistency of AV/C protocol 
15 processing between the node A2 which starts bus reset 
processing after bus reset actually occurs, and the 
node B2 connected to the bus B on which no bus reset 
occurs. Thus, subsequent communication control 
procedures can be smoothly executed, as shown in, e.g., 
20 (3) of Fig. 41. 

As described above, the fifth embodiment provides 
an information communication system including a first 
IEEE 1394 bus connected to an IEEE 1394 bridge, a first 
node connected to the first IEEE 1394 bus, a second 
25 IEEE 1394 bus different from the first IEEE 1394 bus, 

and a second node connected to the second IEEE 1394 bus, 
the first and second nodes communicating with each 
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other, characterized in that the IEEE 1394 bridge 
comprises a means for interpreting an upper protocol 
used by communication between the first and second 
nodes, and a means for performing processing which 
5 should be done by the second node, by the bridge 

instead of the second node when bus reset occurs on the 
first IEEE 1394 bus, and when bus reset occurs on the 
first IEEE 1394 bus, the IEEE bus bridge performs 
processing which should be executed upon occurrence of 

10 bus reset between the first node and the IEEE 1394 

bridge, thereby performing communication between the 
first and second nodes regardless of bus reset on the 
first IEEE 1394 bus. 

According to the fifth embodiment, if bus reset 

15 occurs on one local bus in performing data transfer 
from a data transmission node on one local bus to a 
data reception node connected to the other local bus 
via a 1394 bridge using the same upper protocol, the 
1394 bridge 101 can execute bus reset resume processing 

20 instead of the node on the remote bus. 

As a result, the consistency of bus reset 
processing in the upper protocol layer can be 
maintained without notifying the reception node 
connected to the other bus of occurrence of bus reset. 

25 This realizes normal data communication between buses. 
More specifically, in a system in which a 
plurality of communication control networks (e.g., IEEE 
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1394 buses) are connected via connection devices {e.g., 
IEEE 1394 bridges) , if a network configuration update 
request (e.g., IEEE 1394 bus reset) occurs in one 
communication control network in performing data 
5 transfer from a data transmission communication device 
of one communication network to a data reception 
communication device connected to the other 
communication control network via a connection device 
using the same upper protocol, the connection device 

10 can execute network configuration update resume 
processing instead of the communication device 
connected to the communication control network. The 
consistency of network configuration update request 
processing in the upper protocol layer can be ensured 

15 without notifying the reception communication device 

connected to the other communication control network of 
the network configuration update request. This enables 
normal data communication between communication control 
networks . 

20 [Other Embodiment] 

The present invention may be applied to a system 
constituted by a plurality of devices (e.g., a host 
computer, interface device, reader, and printer) or an 
apparatus comprising a single device (e.g., a copying 

25 machine or facsimile apparatus) . 

The object of the present invention is realized 
even by supplying a storage medium storing software 
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program codes for realizing the functions of the 
above-described embodiments to a system or apparatus, 
and causing the computer (or a CPU or MPU) of the system 
or apparatus to read out and execute the program codes 
5 stored in the storage medium. 

In this case, the program codes read out from the 
storage medium realize the functions of the 
above-described embodiments by themselves, and the 
storage medium storing the program codes constitutes the 

10 present invention. 

As a storage medium for supplying the program 
codes, a floppy disk, hard disk, optical disk, 
magnetooptical disk, CD-ROM, CD-R, magnetic tape, 
nonvolatile memory card, ROM, or the like can be used. 

15 The functions of the above-described embodiments 

are realized not only when the readout program codes are 
executed by the computer but also when the OS (Operating 
System) running on the computer performs part or all of 
actual processing on the basis of the instructions of 

20 the program codes. 

The functions of the above-described embodiments 
are also realized when the program codes read out from 
the storage medium are written in the memory of a 
function expansion board inserted into the computer or a 

25 function expansion unit connected to the computer, and 
the CPU of the function expansion board or function 
expansion unit performs part or all of actual processing 
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on the basis of the instructions of the program codes. 

When the present invention is applied to the 
above storage medium, program codes corresponding to 
the above-described flow charts are stored in this 
5 storage medium. 

As many apparently widely different embodiments 
of the present invention can be made without departing 
from the spirit and scope thereof, it is to be 
understood that the invention is not limited to the 
10 specific embodiments thereof except as defined in the 
appended claims. 



